Wartości graniczne i kontrola obciążenia

TL; DR

Niezawodny obwód to połączenie limitów i kwot na kilku poziomach (krawędź → BFF → servis), sprawiedliwy alokacja zasobów (per-najemca/key/route), SLO-adaptive throttling i backprescher zamiast cichych czasów. Użyj wiadra token/wyciek dla „prędkości”, okno przesuwne dla kwot księgowych, konkurencyjne limity dla ciężkich operacji, dynamiczne przepuszczanie na degradacji i wyłącznik do kruchych w górę strumienia. Wszystko jest pod obserwacją i z odtwarzaczami.

1) Dlaczego limity w iGaming/fintech

SLO i zrównoważony rozwój: ochrona przed lawinami retrasy, szczytami turniejów/imprez, kolcami płatniczymi.
Sprawiedliwość: jeden najemca lub partner nie „wysysa” całego budżetu.
Anti-abuse/bots: login/registration, spam, skrobanie katalogów.
Koszt: ograniczenie kosztownych połączeń (KYC, raporty, agregacje).
Zgodność/uczciwe wykorzystanie: formalne kwoty „fair use” w umowach.

2) Taksonomia graniczna

3) Algorytmy i gdzie stosować

3. 1 wiadro Token (domyślnie)

Parametry: 'szybkość' (żetony/s), 'burst' (maksymalny margines).
Świetnie nadaje się do odczytu API, płatności/statusu, BFF.
Z pustym wiadrem → 429 + 'Retry-After'.

3. 2 Nieszczelne wiadro (uśrednianie)

Gwarantowane „rozbiórki” RPS, przydatne dla haków internetowych, aby nie zdobywać punktów dla pracowników.

3. 3 Okno stałe vs Okno przesuwne

Stałe - proste, ale „granice”; Przesuwanie - uczciwe księgowanie w oknie (min/godzina/dzień).
Zastosuj przesuwanie dla kontyngentów umownych.

3. 4 Równoczesne limity

Ograniczenie jednocześnie aktywnych zadań. Idealny do eksportu/raportów, pakietów KYC, regeneracji.
W przypadku niedoboru - 429/503 + kolejka/sondaż.

3. 5 Ogranicznik kosztów/złożoności

GraphQL/search: rozważyć „koszt” według głębokości/kardynalności/rozszerzeń.
Wycinanie/degradacja „drogich” żądań, odpowiedź z wskazówką.

4) Klucze do wymiarowania

na najemcę (multi-lease, equity),

per-api_key/client_id (partnerzy),

na trasie (poważniejsze mutacje krytyczne),

per-user/device/IP/ASN/geo

BIN/kraj (metody płatności, ochrona emitentów i dostawców),

per-method (GET softer, POST/PUT stricter).

Skład: klucz główny + „mnożnik ryzyka” (nowy rachunek, TOR/proxy, wysokie ryzyko obciążenia zwrotnego).

5) szczelinowanie adaptacyjne SLO

• Wyzwalacze: 'p95 latency „,' 5xx”, 'kolejka len,', 'CPU/IO nasycenie'.
• Działania: niższa szybkość/pęknięcie, umożliwienie wyrzutu na zewnątrz, cięcie „drogich” tras, tymczasowa degradacja (bez ciężkich pól/agregacji).
• Powrót: stopniowo (25 → 50 → 100%) podczas normalizacji sygnałów N kolejnych odstępów czasu.

6) Integracja architektury

Brama API (krawędź): stawka pierwotna/kwoty, geo/ASN, walidacja HMAC/JWT, 429/„ Retry-After ”.
BFF/Service Mesh: cienkie limity na trasie/na najemcę, limity równoległe, wyłączniki do górnego strumienia.
Wewnątrz usługi: semafory do ciężkich operacji, backprescher w kolejkach, „baseny robocze” o rozmiarze związanym.
Webhooks: osobny punkt końcowy ingress z wyciekającym wiadrem i buforem retray.

7) Konfiguracje (fragmenty)

yaml plugins:
- name: rate-limiting config:
policy: local minute: 600    # 10 rps limit_by: consumer fault_tolerant: true
- name: response-ratelimiting config:
limits:
heavy: { minute: 60 }

yaml circuit_breakers:
thresholds: { max_connections: 1000, max_requests: 800 }
outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s http_filters:
- name: envoy. filters. http. local_ratelimit typed_config:
token_bucket: { max_tokens: 100, tokens_per_fill: 100, fill_interval: 1s }
filter_enabled: { default_value: 100% }
filter_enforced: { default_value: 100% }

pseudo sema = Semaphore(MAX_ACTIVE_EXPORTS_PER_TENANT)
if! sema. tryAcquire(timeout=100ms) then return 429 with retry_after=rand(1..5)s process()
sema. release()

pseudo cost = sum(weight(field) cardinality(arg))
if cost > tenant. budget then reject(429,"query too expensive")

8) Polityka dla różnych kanałów

ODPOCZYNEK

GET - miększy, POST/PATCH/DELETE - bardziej rygorystyczny; statusy/kontrole „idempotentne” można wycofać.
W przypadku płatności: limity „auth/capture/refund” na użytkownika/najemcę/BIN/kraj.

GraphQL

Czapki głębokości/złożoności, ciągłe/białe zapytania, limity pseudonimów.

WebSocket/SSE

Limit częstotliwości 'subscribe/unsubscribe', czapka na liczbę tematów, kontrola wielkości zdarzeń i send-queue → kiedy 'policy _ disconnect' overflow.

Haki internetowe

Nieszczelne wiadro w recepcji, kwoty na nadawcę, kolejka martwych liter, deterministyczne 2xx/429.

9) Opinie klientów

• 'Retry-After: '
• 'Limit-Limit-X/Pozostały/Reset'
• Dla kontyngentów - 403 z kodem „quota _ exceeded” i linkiem do aktualizacji planu.
• Dokumentacja: limity na stronach OpenAPI/SDL + „Fair Use”.

10) Monitoring i deski rozdzielcze

• Limity trafień: 'rate. limit. hit 'przez klucze/routs/najemców.
• 429/503 дола, latency p50/p95/p99, szybkość błędów, długość kolejki, obwody otwarte.
• Fair-share: najlepsi najemcy w konsumpcji, „bully detector”.
• Webhooks: recepcja/retrai, drop-rate, middle lag.

• 429 nie więcej niż 1-3% całkowitego RPS (bez botów).
• Dodatek ogranicznika p95 ≤ 5-10 ms na krawędź.
• Czas regeneracji degradacji ≤ 10 min.

sql
SELECT ts::date d, tenant, route,
SUM(hits) AS limit_hits,
SUM(total) AS total_calls,
SUM(hits)::decimal/NULLIF(SUM(total),0) AS hit_rate
FROM ratelimit_stats
GROUP BY 1,2,3
ORDER BY d DESC, hit_rate DESC;

11) Playbooks incydentów

Burza retray (upstream fall): włączyć globalne throttling, podnieść backoff, open circuit-breaker, powrócić „szybkie błędy” zamiast timeouts.
Bot attack/scraping: hard cap by IP/ASN/geo, enable WAF/JS challenge, restrict directories/search.
Turniej/szczyt wydarzeń: wstępnie podnieść limity odczytu, niższe „drogie pola”, włączyć pamięć podręczną/denormalizację.
Dodano haki internetowe z PSP: tymczasowe wyciekające wiadro, priorytetyzacja typów krytycznych, rozszerzenie martwej litery i retray.

12) Badania i UAT

Obciążenie: drabina RPS, koraliki × 10 normalnych.
Sprawiedliwość: emulacja 1 „chciwego” najemcy - nie więcej niż X% globalnego budżetu.
Degradacja: adaptacja SLO zmniejsza granice i utrzymuje p95 w korytarzu.
Przypadki graniczne: zmiana okna (min → chas), wstrząs zegara (skew zegara), skalowanie Redis/shading klucza.
Kontrakt: 429 i nagłówki Retry-After są obecne, SDK jest prawidłowo wycofane.

13) Przechowywanie dla limitów

Pamięć dla lokalnych limitów (małych klastrów).
Redis/Memcached dla rozproszonych (Lua skrypty dla atomowości).
Shading keys przez hash; TTL pod oknami; backup metric dla utraty pamięci podręcznej.
Idempotencja: ogranicznik nie powinien łamać idempotentnych powtarzających się połączeń (księgowanie za pomocą klucza żądania).

14) Zarządzanie

Katalog limitów: kto jest właścicielem, jakie klucze/próg/ratyfikowany.
Flagi funkcji dla szybkich przełączników (tryb kryzysowy).
Polityka weryfikacyjna i proces RFC w zakresie zmian kontyngentów umownych.
Eksperymenty A/B dotyczące doboru optymalnych progów.

15) Anty-wzory

Globalny jeden limit „dla wszystkich API”.
Tylko stałe okna → skoki „krawędzi”.
Limit bez informacji zwrotnej (brak nagłówków 'Retry-After').
Ciche czasy zamiast szybkiego 429/503.
Brak uczciwego udziału jednego najemcy - jeden klient udusi resztę.
Brak ochrony wyszukiwania GraphQL/złożoności.
Zera w równoległej straży → DB/PSP „odkurzacz”.

16) Mini oszustwo arkusz wyboru

Domyślnie jest wiadro token (szybkość + pęknięcie) na-najemca + trasa.
Kwoty według pieniędzy/raportów: przesuwne okno dzień/miesiąc.
Ciężkie operacje: równoległe limity + kolejka.
GraphQL/боиса: złożoność-budżety + trwałe zapytania.
WS/webhooks: wyciekły wiadro + backpressure.
КрикИZ: throttling dynamiczny + circuit-breaker + degrade.

Podsumowanie

Kontrola obciążenia to dyscyplina wielopoziomowa: poprawne algorytmy (wiadro/okna/konkurencyjność), sprawiedliwe klucze limitu, adaptacja SLO i przejrzyste sprzężenie zwrotne. Poprzez szycie limitów w bramę/siatkę/usługi, uzbrojenie GraphQL/WS/webhooks z zasadami profilu i łączenie obserwowalności z odtwarzaczami, zmieniasz maksymalne zdarzenia i awarie innych ludzi w sytuacje kontrolowane - bez awarii, zakłóconych płatności i wypłat z konwersji.