Rate limits va kvotalar

Rate limits va kvotalar - bu umumiy resurslarga bo’lgan talabni boshqarishning fundamental mexanikasi: CPU, tarmoq, DD, navbatlar, tashqi API. Maqsad - adolat (fairness), SLOni oldindan aytib bo’ladigan va portlashlar, suiiste’molliklar va «noisy neighbor» dan himoya qilish.

1) Bazaviy tushunchalar

Rate limit - so’rovlar/operatsiyalar intensivligini cheklash (req/s, msg/min, bayt/sek).
Burst - oʻrtacha rate ustidagi ruxsat etilgan qisqa muddatli koʻtarilish.
Quota - vaqt oynasi uchun hajm limiti (hujjatlar/sutka, GB/oy).
Concurrency cap - bir vaqtning o’zida amalga oshiriladigan operatsiyalarni cheklash (bir vaqtning o’zida so’rovlar/joblar).
Scope - qo’llanish sohasi: per-tenant, per-user, per-token, per-endpoint, per-IP, per-region, per-feature.

2) Limitlash algoritmlari

2. 1 Token Bucket (tokenli chelak)

Parametrlar:’rate’(tokenlar/sek),’burst’(chelak oʻlchami).
«Kredit» kabi ishlaydi: to’plangan tokenlar qisqa cho’qqilarga imkon beradi.
Tashqi API va foydalanuvchi soʻrovlari uchun mos keladi.

2. 2 Leaky Bucket (oqadigan chelak)

Oqimni doimiy tezlikda siljitadi.
Nozik backend’amlarga trafikni yumshatish uchun yaxshi.

2. 3 Fixed/Sliding Window

Fixed window: oddiy, ammo «oynani almashtirish» ga zaif.
Sliding window: aniqrog’i, lekin hisoblash uchun qimmatroq.

2. 4 GCRA (Generic Cell Rate Algorithm)

Virtual kelish vaqtidagi Token Bucket ekvivalenti.
Taqsimlangan limiterlar uchun aniq va barqaror (kamroq ziddiyatli state).

2. 5 Concurrency Limits

Bir vaqtning o’zida bajariladigan operatsiyalarni cheklash.
Oqim/ulanish hovuzlari va «head-of-line blocking» ning tugashidan himoya qiladi.

3) Limitlarni qayerda qo’llash

Chegarada (L7/API-shlyuz): asosiy to’siq, tezkor rad etish (429/503), arzon tekshiruvlar.
Xizmatlar ichida: og’ir operatsiyalar uchun qo’shimcha caps (eksport, hisobotlar, transformatsiyalar).
Tashqi tizimlarga chiqishda: uchinchi tomonlar uchun individual limitlar (anti-penalty).
Navbatlarda/vorkerlarda: fairness umumiy pullarga.

4) Tovarlar va ustuvorliklar (multi-tenant)

Иерархия: Global → Region → Tenant/Plan → User/Token → Endpoint/Feature → IP/Device.
Priority-aware: VIP/Enterprise katta’burst’va og’irlikni oladi, lekin umumiy SLOlarni buzmaydi.
Limitlar kompozitsiyasi: yakuniy ruxsat =’min (global, mintaqaviy, tenant, foydalanuvchi, endpoint)’.

5) Hajm bo’yicha kvotalar

Sutkalik/oylik kvotalar: hujjatlar/sutka, GB/oy, xabarlar/min.
Yumshoq/qattiq chegaralar: ogohlantirishlar (80/90%) va «qattiq to’xtash».
Roll-up: obyektlar (jadvallar, fayllar, hodisalar) bo’yicha hisobga olish va billingga «olish».

6) Taqsimlangan limiterlar

Talablar: past kechikish, muvofiqlik, nosozliklarga chidamlilik, gorizontal masshtablash.

Local + probabilistic sync: lokal shardli chelaklar + davriy sinxronlash.
Central store: Redis/KeyDB/Memcached с LUA/atomic ops (INCR/PEXPIRE).
Sharding:’limit: {scope}: {id}: {window}’turining kalitlari.
Clock skew: «Haqiqatni» mijozlarda emas, balki limiter serverida saqlash.
Idempotentlik: «operatsiyalar» (Idempotency-Key) kalitlari yolg’on hisobdan chiqarishni kamaytiradi.

7) Anti-abyuz va himoya

Ommaviy endpointlar uchun Per-IP + device fingerprint.
Proof-of-Work/CAPTCHA anomaliyalarda.
Slowdown (throttling) to’liq rad etish o’rniga, UX muhimroq bo’lganda (qidiruv maslahatlari).
Adaptive limits: hodisalar/qimmat degradatsiyalarda chegaralarning dinamik pasayishi.

8) Mijozning xatti-harakati va bayonnoma

Kodlari:’429 Too Many Requests’(rate),’403’(kvota/rejadan oshib ketgan),’503’(himoya degradatsiyasi).

• ’Retry-After: ’ - qachon qaytadan urinib koʻriladi.

• `RateLimit-Limit: ;w=`
• `RateLimit-Remaining: `
• `RateLimit-Reset: `
• Backoff: eksponensial + jitter (full jitter, equal jitter).
• Idempotentlik: «Idempotency-Key» sarlavhasi va xavfsiz operatsiyalarning takrorlanuvchanligi.
• Taym-autlar va bekor qilish: chegaralarni «tortib olmaslik» uchun osilgan so’rovlarni to’g’ri to’xtatish.

9) Kuzatish va test sinovlari

Теги: `tenant_id`, `plan`, `user_id`, `endpoint`, `region`, `decision` (allow/deny), `reason` (quota/rate/concurrency).
Metriklar: o’tkazish qobiliyati, 429/403/503 nosozliklari ulushi, limiter kechikishi p95/p99, kalitlar keshining hit ratio, rejalar bo’yicha taqsimlash.
Audit loglari: bloklar sabablari, yuqori «shovqinli» kalitlar.
Testlar: «arra/burst/plato» yuklash profillari, xaos - Redis/shardning ishdan chiqishi, soatlarning sinxronizatsiyasi.

10) Billing bilan integratsiya

Usage-hisoblagichlar chegarada yig’iladi, idempotentlik bilan batchlar (har N min) bilan yig’iladi.
Rejalar boʻyicha maʼlumot: ortiqcha sarflash → overchardj yoki rejani vaqtincha oshirish.
Tafovutlar: solishtirish usage vs invoice; delta tomon alertalar.

11) Ichkaridagi fairness (navbatlar, vorkerlar)

Weighted Fair Queuing/DRR: reja og’irligi bo’yicha ijarachilar o’rtasida slotlarni taqsimlash.
Per-tenant worker pools: qattiq izolyatsiya VIP/shovqinli.
Admission control: agar kvotalar tugagan bo’lsa, bajarishdan oldin rad etish; navbatlar ko’paymaydi.
Caps on concurrency: bir vaqtning oʻzida ogʻir joblarni cheklash.

12) Rejalarning namunaviy profillari (misol)

yaml plans:
starter:
rate: 50  # req/s burst: 100 concurrency: 20 quotas:
daily_requests: 100_000 monthly_gb_egress: 50 business:
rate: 200 burst: 400 concurrency: 100 quotas:
daily_requests: 1_000_000 monthly_gb_egress: 500 enterprise:
rate: 1000 burst: 2000 concurrency: 500 quotas:
daily_requests: 10_000_000 monthly_gb_egress: 5000

13) Arxitektura etaloni (so’z sxemasi)

1. Edge/API-shlyuz: TLS → kontekstni (tenant/plan) olish → limitlar/kvotalarni tekshirish → RateLimit- → log/treys sarlavhalarini joylashtirish.
2. Policy Engine: ustuvorlik qoidalari (VIP), moslashuvchan chegaralar.
3. Limiter Store: Redis/KeyDB (atomic ops, LUA), kalitlarni shardalash, replikatsiya.
4. Services: og’ir operatsiyalar uchun ikkilamchi limit va caps; idempotentlik; WFQ/DRR bilan navbatlar.
5. Usage/Billing: to’plash, agregatsiya, invoys, ostonalar bo’yicha alertlar.
6. Observability: metriklar/loglar/treyslar bilan teglar, dashbordlar per-tenant.

14) Sotishdan oldingi chek-varaq

• Limit scoplari (tenant/user/token/endpoint/IP) va ularning ierarxiyasi aniqlangan.
• Algoritm (Token Bucket/GCRA) va’rate/burst’parametrlari tanlangan.
• Og’ir operatsiyalar uchun concurrency caps va admission control amalga oshirildi.
• "RateLimit-’va" Retry-After "sarlavhalari kiritilgan; mijozlar backoff + jitterni qoʻllab-quvvatlaydilar.
• Taqsimlangan va nosozliklarga chidamli limiter (sharlar, replikatsiya, degradatsiya).
• Usage-yig’im idempotenten; billing bilan bog’lash, ortiqcha sarflash uchun alertlar.
• Kuzatish darajasi: metriklar/treyslar/loglar, yuqori «shovqinli» kalitlar, alerter’lar.
• Testlar: burstlar, «arra», nosozlik, clock skew, sovuq start.
• Mijozlar uchun hujjatlar: rejalar bo’yicha limitlar, 429/Retry-After namunalari, retraylarning best practices.
• Istisnolar siyosati: vaqtincha limitlarni qanday oshirish va qachon.

15) Tipik xatolar

Jitterli idempotentlik va retraylar yoʻq

Global limitsiz per-tenant/per-endpoint - «noisy neighbor» barcha SLOlarni buzadi.
Yo’q’burst’: UX qisqa portlashlarda azob chekadi.
Faqat oʻrnatilgan oyna → «oyna chegarasida ikki marta urish».
Cheklovlar faqat chegarada, servislarda/navbatlarda caps’siz → ichki «tiqinlar».
Javoblarda limitlarni aks ettirmaslik (’Retry-After’,’RateLimit-’) → mijozlar moslashmaydi.
OLTP DB → yuqori latentlik va «issiq» blokirovkalarda limiter holatini saqlash.

16) Strategiyani tez tanlash

Ochiq APIlar: Token Bucket + katta’burst’, RateLimit- sarlavhalar, CDN/edge kesh.
Ichki og’ir joblar: concurrency caps + WFQ/DRR, admission control.
Uchinchi tomonlar bilan integratsiyalashuv: chiqish, buferlash/retraj uchun alohida limitlar.
Multi-tenant SaaS: limitlar ierarxiyasi (global → tenant → user → endpoint), VIP ustuvorligi, oylar bo’yicha kvotalar.

Xulosa

Yaxshi rate limits va kvotalar - bu platforma va mijoz o’rtasidagi tizimli shartnoma: resurslarning halol ulushi, portlashlarga chidamlilik, bashorat qilinadigan SLO va shaffof billing. Algoritmlarni (Token/GCRA + concurrency caps) birlashtiring, skoplar ierarxiyasini joriy qiling, tushunarli sarlavhalar va metrikalarni bering va haqiqiy trafik profillari ostidagi sxemalarni muntazam ravishda tekshiring - bu platforma yukning agressiv o’sishi bilan ham barqaror bo’lib qoladi.