GH GambleHub

Rate Limits va yuk nazorati

TL; DR

Ishonchli kontur - bu bir nechta darajadagi limitlar va kvotalarning kombinatsiyasi (edge → BFF → servis), resurslarning adolatli taqsimlanishi (per-tenant/kalit/rout), SLO-moslashuvchan trottling va sukut saqlovchi taym-autlar o’rniga backpresher. «Tezlik» uchun token/leaky bucket, buxgalteriya kvotalari uchun harakatlanuvchi oyna, og’ir operatsiyalar uchun raqobat limitlari, degradatsiyada dynamic throttling va mo’rt apstrimlarga circuit-breaker’dan foydalaning. Hammasi kuzatuv ostida va pleybuklar bilan.

1) Nima uchun iGaming/fintech limitlari

SLO va barqarorlik: retray ko’chkilaridan, turnirlar/eventlar cho’qqilaridan, to’lovlarning ko’tarilishidan himoya qilish.
Adolat: bitta tenant yoki sherik butun byudjetni «soʻrmaydi».
Antiabyuz/botlar: login/ro’yxatdan o’tish, spam, skraping kataloglarini dorilimiting.
Qiymati: qimmatbaho chaqiriqlarni jilovlash (KYC, hisobotlar, agregatsiyalar).
Komplayens/vijdonan foydalanish: shartnomalardagi rasmiy «fair use» kvotalari.

2) Limitlar taksonomiyasi

KategoriyaNima uchunKalit namunalari
Rate (tezlik)Barqaror RPS, burstlardan himoya qilish`api_key`, `tenant`, `route`, `country`, `BIN`
Quota (buxgalteriya)Qimmatbaho resurslar bo’yicha sutka/oy`tenant-day`, `partner-month`, `report-type`
ConcurrentParallel ogʻir amallarni cheklash`payout:create`, `export:csv`, `recalc`
Cost-basedMurakkab/qimmat soʻrovlar (GraphQL/qidirish)«kompleksliligi», javob miqdori
AdaptiveSLO/yashirin/xatoga munosabatglobal/perrout
Ingress/egressVebxuklarni qabul qilish`webhook-receiver`, `psp-outbound`

3) Algoritmlar va qayerda qo’llash

3. 1 Token Bucket (andoza)

Parametrlar:’rate’(tokenlar/sek),’burst’(maksimal zaxira).
API o’qish, to’lov/maqomlar, BFF uchun juda yaxshi.
Bo’sh baketada → 429 +’Retry-After’.

3. 2 Leaky Bucket (o’rtacha)

Kafolatlangan RPS «buzish» vebxuklar uchun foydalidir.

3. 3 Fixed Window vs Sliding Window

Fixed - oddiy, lekin «chegara»; Sliding - oynada halol hisobga olish (min/soat/sutka).
Shartnoma kvotalari uchun Sliding’dan foydalaning.

3. 4 Concurrent Limits

Bir vaqtning o’zida faol vazifalar limiti. Eksport/reportaj, KYC paketlari, qayta ishlash uchun ideal.
Kamomad - 429/503 + navbat/polling.

3. 5 Cost/Complexity Limiter

GraphQL/qidirish: «qiymatni» chuqurlik/kardinallik/kengaytmalar bo’yicha hisoblaymiz.
«Qimmat» so’rovlarni kesish/degradatsiya qilish, ko’rsatma bilan javob berish.

4) Limitlash kalitlari (dimensioning)

per-tenant (multiarenda, adolat),

per-api_key/client_id (sheriklar),

per-route (tanqidiy mutatsiyalar qattiqroq),

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

per-BIN/country (to’lov usullari, emitentlar va provayderlarni himoya qilish),

per-method (GET yumshoqroq, POST/PUT qattiqroq).

Kompozitsiya: asosiy kalit + «xavf multiplikatori» (yangi hisobvaraq, TOR/proksi, yuqori chargeback-xavf).

5) SLO-adaptiv trottling

SLO xavf ostida bo’lganda dynamic throttling’ni yoqing:
  • Triggerlar:’p95 latency ↑’,’5xx ↑’,’queue len ↑’,’CPU/IO saturation’.
  • Amallar: rate/burst ni pasaytirish, outlier-ejection ni yoqish, «qimmat» routlarni qisqartirish, vaqtinchalik degrade (ogʻir maydonlarsiz/agregatsiyalarsiz).
  • Qaytarish: ketma-ket N oraliq signallarni normallashtirishda bosqichma-bosqich (25 → 50 → 100%).

6) Arxitekturaga integratsiya qilish

API Gateway (edge): birlamchi rate/quotas, geo/ASN, HMAC/JWT-validatsiya, 429/’ Retry-After’.
BFF/Service Mesh: ingichka per-route/per-tenant limitlar, concurrent-limits, circuit-breakers to apstrimlarga.
Xizmat ichida: og’ir operatsiyalar uchun semaforlar, navbatdagi bekpresher, bound o’lchamli «ish pullari».
Vebxuki: leaky bucket va retray buferi bilan alohida ingress-endpoint.

7) Konfiguratsiyalar (parchalar)

Kong / NGINX-style (rate + burst):
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 }
Envoy (circuit + outlier + rate):
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% }
Concurrent-limits (psevdo):
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()
GraphQL cost guard (gʻoya):
pseudo cost = sum(weight(field) cardinality(arg))
if cost > tenant. budget then reject(429,"query too expensive")

8) Turli kanallar uchun siyosatlar

REST

GET - yumshoqroq, POST/PATCH/DELETE - qattiqroq; «idempotent» maqomlarni/tekshirishlarni retraj qilish mumkin.
To’lovlar uchun:’auth/capture/refund’per-user/tenant/BIN/mamlakat limitlari.

GraphQL

Depth/complexity caps, persisted/whitelisted queries, limitlar «alias».

WebSocket/SSE

Chastota limiti’subscribe/unsubscribe’, topiklar soniga kap, hodisalar oʻlchamini nazorat qilish va’policy _ disconnect’toʻldirilganda send-queue →.

Vebxuki

Leaky bucket qabul qilishda, per-sender kvotalari, dead-letter navbati, determinirlangan 2xx/429.

9) Mijozlarga qayta aloqa

Har doim sarlavhalar bilan aniq 429 ni qaytaring:
  • `Retry-After: `
  • `X-RateLimit-Limit/Remaining/Reset`
  • Kvotalar uchun - 403’quota _ exceeded’kodi va reja jadvaliga havola bilan.
  • Hujjatlar: OpenAPI/SDL + «Fair Use» sahifalaridagi limitlar.

10) Monitoring va dashbordlar

Metriklar:
  • Limitlar xiti:’rate. limit. hit’kalitlar/routlar/tenantlar bo’yicha.
  • 429/503 доля, latency p50/p95/p99, error rate, queue length, open circuits.
  • Fair-share: iste’mol bo’yicha top-tenantlar, «bully detector».
  • Vebxuklar: qabul/retraj, drop-rate, oʻrta lag.
SLO koʻrsatkichlari:
  • 429 umumiy RPSning 1-3% dan ortiq emas (botsiz).
  • p95 limiter qo’shish ≤ edge uchun 5-10 ms.
  • Degradatsiyadan keyin tiklanish vaqti ≤ 10 daqiqa.
SQL namunasi (kalitlar boʻyicha kesma):
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) Hodisalar pleybuklari

Retray bo’roni (apstrimning tushishi): global throttling ni yoqish, backoffni ko’tarish, circuit-breaker ochish, taym-autlar o’rniga «tez xatolarni» qaytarish.
Bot-hujum/skreyping: IP/ASN/geo bo’yicha qattiq qopqoq, WAF/JS-challenge, kataloglarni cheklash/qidirish.
Turnir/event cho’qqisi: o’qish limitlarini oldindan ko’tarish, «qimmatbaho maydonlar» ni kamaytirish, kesh/denormalizatsiyani yoqish.
PSP vebxuklarini toʻldirish: vaqtinchalik leaky bucket, tanqidiy turlarni ustuvorlashtirish, dead-letter va retrajlarni kengaytirish.

12) Test va UAT

Yuk ortish: RPS zinapoyalar, burstlar × normaldan 10.
Adolat: 1 ta «ochko’z» tenantning emulyatsiyasi - global byudjetning X foizidan ko’p emas.
Degradatsiya: SLO moslashuvi chegaralarni qisqartiradi va p95 ni koridorda ushlab turadi.
Cheklangan keyslar: oynani almashtirish (min → soat), soat titrashi (clock skew), Redis/sharding kalitlarini kattalashtirish.
Kontrakt: 429 va Retry-After sarlavhalari mavjud, SDK to’g "ri bek-offit.

13) Limitlar saqlanadigan ombor

Lokal limitlar uchun In-memory (kichik klasterlar).
Taqsimlangan uchun Redis/Memcached (atom uchun Lua skriptlari).
Xesh boʻyicha kalitlarni shardlash; TTL deraza ostiga; keshni yo’qotish uchun bekap-metrika.
Idempotency: limiter idempotent takroriy chaqiruvlarni buzmasligi kerak (soʻrov kaliti boʻyicha hisobga olish).

14) Siyosatni boshqarish (Governance)

Limitlar katalogi: kim egasi, qaysi kalitlar/chegara/ratsional.
Tezkor almashtirgichlar uchun feature-flags (crisis mode).
Shartnomaviy kvotalarni o’zgartirish siyosati va RFC jarayonini versionizatsiya qilish.
A/B optimal chegaralarni tanlash bo’yicha tajribalar.

15) Anti-patternlar

Butun API uchun global bitta limit.
Faqat oʻrnatilgan oynalar → «chekka» poygalar.
Qayta aloqasiz limit (no’Retry-After ’/headers).
Tezkor 429/503 o’rniga sukut saqlovchi taym-autlar.
per-tenant fair-share yo’qligi - bitta mijoz boshqalarni bo’g’ib o’ldiradi.
GraphQL/qidirish himoyasi mavjud emas.
Nullar concurrent-guard → «changyutgich» DB/PSP.

16) Tanlash mini-shpargalkasi

Andoza: token bucket (rate + burst) per-tenant + route.
Pul/hisobotlar bo’yicha kvotalar: sliding window sutka/oy.
Og’ir operatsiyalar: concurrent-limits + navbat.
GraphQL/поиск: complexity-budgets + persisted queries.
WS/vebxuklar: leaky bucket + backpressure.
Кризис: dynamic throttling + circuit-breaker + degrade.

Xulosa

Yuklamani nazorat qilish - bu koʻp darajali intizom: toʻgʻri algoritmlar (bucket/deraza/raqobatbardoshlik), adolatli cheklash kalitlari, SLO moslashuvi va shaffof qayta aloqa. Gateway/mesh/servislarga limitlar qo’shib, GraphQL/WS/vebxuklarni maxsus polislar bilan jihozlab, kuzatuvni pleybuklar bilan bog’lab, siz eng yuqori hodisalarni va boshqalarning nosozliklarini boshqariladigan holatlarga aylantirasiz - bo’yoqlarsiz, to’lovlarsiz va konvertatsiya qilmasdan.

Contact

Biz bilan bog‘laning

Har qanday savol yoki yordam bo‘yicha bizga murojaat qiling.Doimo yordam berishga tayyormiz.

Integratsiyani boshlash

Email — majburiy. Telegram yoki WhatsApp — ixtiyoriy.

Ismingiz ixtiyoriy
Email ixtiyoriy
Mavzu ixtiyoriy
Xabar ixtiyoriy
Telegram ixtiyoriy
@
Agar Telegram qoldirilgan bo‘lsa — javob Email bilan birga o‘sha yerga ham yuboriladi.
WhatsApp ixtiyoriy
Format: mamlakat kodi va raqam (masalan, +998XXXXXXXX).

Yuborish orqali ma'lumotlaringiz qayta ishlanishiga rozilik bildirasiz.