Rate Limits və yük nəzarəti

TL; DR

Etibarlı kontur bir neçə səviyyədə limit və kvotaların birləşməsidir (edge → BFF → xidmət), resursların ədalətli bölüşdürülməsi (per-tenant/açar/rout), SLO-adaptiv trottling və səssiz zaman-aut əvəzinə backpresher. «Sürət» üçün token/leaky bucket istifadə edin, mühasibat kvotaları üçün sürüşmə pəncərəsi, ağır əməliyyatlar üçün rəqabət limitləri, deqradasiya zamanı dynamic throttling və kövrək axınlara circuit-breaker. Hər şey - müşahidə altında və playbook ilə.

1) Niyə iGaming/fintech limitləri

SLO və stabillik: retraj uçqunlarından, turnirlərin/eventlərin zirvələrindən, ödəniş sıçrayışlarından qorunma.
Ədalət: bir tenant və ya tərəfdaş bütün büdcəni «sormur».
Anti-sui-istifadə/botlar: login/qeydiyyat, spam, scraping kataloq dorilimiting.
Qiymət: bahalı çağırışların qarşısını almaq (KYC, hesabatlar, aqreqasiyalar).
Komplayens/vicdanla istifadə: müqavilələrdə rəsmi «fair use» kvotaları.

2) Limit taksonomiyası

3) Alqoritmlər və harada tətbiq

3. 1 Token Bucket (default)

Parametrlər: 'rate' (token/san), 'burst' (max ehtiyat).
API oxu, ödəniş/status, BFF üçün əla.
Boş baket ilə → 429 + 'Retry-After'.

3. 2 Leaky Bucket (orta)

Garantili «sökülmə» RPS, WebChooks üçün faydalıdır.

3. 3 Fixed Window vs Sliding Window

Fixed - sadə, lakin «sərhədləri»; Sliding - pəncərədə dürüst uçot (min/saat/gün).
Müqavilə kvotaları üçün Sliding tətbiq edin.

3. 4 Concurrent Limits

Aktiv tapşırıqların limiti. İxrac/reportaj, KYC paketləri, təkrar emal üçün idealdır.
Çatışmazlıq - 429/503 + növbə/polling.

3. 5 Cost/Complexity Limiter

GraphQL/axtarış: dərinlik/kardinallıq/uzantıları ilə «dəyəri» hesab.
«Bahalı» sorğuların kəsilməsi/deqradasiyası, ipucu ilə cavab.

4) Limit açarları (dimensioning)

per-tenant (multi-icarə, ədalət),

per-api_key/client_id (tərəfdaşlar),

per-route (kritik mutasiyalar daha sərt),

per-user/device/IP/ASN/geo (antibot/antiskreyp),

per-BIN/country (ödəniş metodları, emitentlərin və provayderlərin qorunması),

per-method (GET daha yumşaq, POST/PUT daha sərt).

Kompozisiya: əsas açar + «risk multiplikatoru» (yeni hesab, TOR/proxy, yüksək chargeback-risk).

5) SLO adaptiv trottling

• Triggerlər: 'p95 latency ↑', '5xx ↑', 'queue len ↑', 'CPU/IO saturation'.
• Fəaliyyət: rate/burst aşağı, outlier-ejection daxil, «bahalı» routes kəsmək, müvəqqəti degrade (ağır sahələr/aqreqasiya olmadan).
• Geri dönüş: ardıcıl N intervallarının siqnallarının normallaşdırılması zamanı mərhələli (25 → 50 → 100%).

6) Arxitekturaya inteqrasiya

API Gateway (edge): ilkin rate/quotas, geo/ASN, HMAC/JWT-validasiya, 429/' Retry-After '.
BFF/Service Mesh: incə per-route/per-tenant limitləri, concurrent-limits, circuit-breakers axınlara.
Xidmət daxilində: ağır əməliyyatlar üçün semaforlar, növbələrdə backpresher, bound ölçülü «iş hovuzları».
Vebhuki: leaky bucket və retrai bufer ilə ayrıca ingress-end point.

7) Konfiqurasiya (fraqmentlər)

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) Müxtəlif kanallar üçün siyasət

REST

GET - daha yumşaq, POST/PATCH/DELETE - daha sərt; «idempotent» status/yoxlamalar retraj edilə bilər.
Ödənişlər üçün: limitlər 'auth/capture/refund' per-user/tenant/BIN/ölkə.

GraphQL

Depth/complexity caps, persisted/whitelisted queries, «alias» limitləri.

WebSocket/SSE

'subscribe/unsubscribe' tezlik limiti, topik sayı, hadisə ölçüsü nəzarət və send-queue → 'policy _ disconnect' aşdıqda.

Webhucks

Leaky bucket qəbulu, per-sender kvotaları, dead-letter növbə, determinated 2xx/429.

9) Müştəri rəyləri

• `Retry-After: `
• `X-RateLimit-Limit/Remaining/Reset`
• Kvotalar üçün - 403 'quota _ exceeded' kodu və plan yeniləməsinə keçid ilə.
• Sənədləşmə: OpenAPI/SDL + «Fair Use» səhifələrində limitlər.

10) Monitorinq və Daşbordlar

• Limitlərin hitləri: 'rate. limit. açarları/marşrutları/tenantları ilə hit '.
• 429/503 доля, latency p50/p95/p99, error rate, queue length, open circuits.
• Fair-share: istehlak üzrə top-tenantlar, «bully detector».
• Vebhuki: qəbul/retrai, drop-rate, orta gecikmə.

• 429 ümumi RPS-nin 1-3% -dən çox deyil (botlar olmadan).
• p95 limiter əlavə edge ≤ 5-10 ms.
• Deqradasiyadan sonra bərpa müddəti ≤ 10 dəqiqə.

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) Hadisə pleybukları

Fırtına retrains (axın düşməsi): qlobal throttling yandırmaq, backoff qaldırmaq, circuit-breaker açmaq, vaxt-out əvəzinə «sürətli səhvlər» qaytarmaq.
Bot-hücum/scraping: IP/ASN/geo sərt cap, WAF/JS-challenge daxil, kataloqlar/axtarış məhdudlaşdırmaq.
Tournament/event zirvəsi: oxu limitlərini artırmaq, «bahalı sahələri» azaltmaq, cache/denormalizasiya daxil etmək.
PSP-dən vebhukları boşaltın: müvəqqəti leaky bucket, kritik tiplərin prioritetləşdirilməsi, dead-letter və retrayları genişləndirin.

12) Test və UAT

Yük: RPS pilləkən, burst × normal 10.
Ədalət: 1 «acgöz» tenantın emulyasiyası - qlobal büdcənin X% -dən çox deyil.
Deqradasiya: SLO adaptasiyası limitləri azaldır və p95-i dəhlizdə saxlayır.
Sərhəd halları: pəncərənin dəyişdirilməsi (min → saat), saat titrəməsi (clock skew), Redis/açarların ölçülməsi.
Müqavilə: başlıqlar 429 və Retry-After mövcuddur, SDK düzgün geri offit.

13) Limitlər üçün saxlama

Yerli limitlər üçün In-memory (kiçik klasterlər).
dağıdılmış üçün Redis/Memcached (atom üçün Lua skriptləri).
Hash açarları; TTL pəncərələrin altında; cache itirmək üçün backup metrika.
Idempotency: Limiter idempotent təkrar zəngləri pozmamalıdır (sorğu açarı ilə uçot).

14) Siyasətin idarə edilməsi (Governance)

Limitlər kataloqu: kim sahibidir, hansı açarlar/eşik/rasional.
Sürətli açarlar üçün feature-flags (crisis mode).
Müqaviləli kvotaların dəyişdirilməsi üçün siyasət və RFC prosesi versiyası.
A/B optimal eşik seçimi üçün təcrübələr.

15) Anti-nümunələr

Qlobal bir limit «bütün API».
Yalnız sabit pəncərələr → «kənar» at yarışları.
Geribildirim olmadan limit (no 'Retry-After '/headers).
Sürətli 429/503 əvəzinə səssiz vaxt.
per-tenant fair-share olmaması - bir müştəri digərlərini boğur.
GraphQL qorunması/mürəkkəbliyə görə axtarış yoxdur.
Nuls concurrent-guard → «tozsoran» DD/PSP.

16) Mini seçim stick

Default: token bucket (rate + burst) per-tenant + route.
Pul/hesabat kvotaları: sliding window gün/ay.
Ağır əməliyyatlar: concurrent-limits + növbə.
GraphQL/поиск: complexity-budgets + persisted queries.
WS/vebhuk: leaky bucket + backpressure.
Кризис: dynamic throttling + circuit-breaker + degrade.

Xülasə

Yük nəzarəti çox səviyyəli bir intizamdır: düzgün alqoritmlər (bucket/pəncərə/rəqabət), ədalətli limit açarları, SLO adaptasiyası və şəffaf rəy. gateway/mesh/servislərə limitlər əlavə edərək, GraphQL/WS/vebhukları profil polisləri ilə təchiz edərək və playbuklarla müşahidə imkanlarını birləşdirərək, pik hadisələri və başqalarının uğursuzluqlarını idarə olunan vəziyyətlərə çevirirsiniz - boyalar, pozulmuş ödənişlər və dönüşümlər olmadan.