Rate limits və kvotalar

Rate limits və kvotalar ümumi resurslara tələbin idarə edilməsinin fundamental mexanikasıdır: CPU, şəbəkə, DB, növbələr, xarici API. Məqsəd ədalət (fairness), SLO-nun proqnozlaşdırılması və sıçrayışlardan, sui-istifadədən və "noisy neighbor 'dan qorunmaqdır.

1) Əsas anlayışlar

Rate limit - sorğuların/əməliyyatların intensivliyinin məhdudlaşdırılması (req/s, msg/min, bayt/san).
Burst - orta rate üzərində icazə verilən qısa müddətli sıçrayış.
Quota - vaxt pəncərəsi üçün həcm limiti (sənəd/gün, GB/ay).
Concurrency cap - eyni zamanda əməliyyatların məhdudlaşdırılması (eyni zamanda sorğular/joblar).
Scope - tətbiq sahəsi: per-tenant, per-user, per-token, per-enpoint, per-IP, per-region, per-feature.

2) Limit alqoritmləri

2. 1 Token Bucket (Token kovası)

Parametrlər: 'rate' (token/san), 'burst' (vedrə ölçüsü).
«Kredit» kimi işləyir: yığılmış tokenlər qısa zirvələrə imkan verir.
Xarici API və istifadəçi sorğuları üçün uyğundur.

2. 2 Leaky Bucket (sızan kova)

Sabit sürətlə axını rəvan «vurur».
Həssas backend 'am üçün trafikin hamarlanması üçün yaxşıdır.

2. 3 Fixed/Sliding Window

Fixed window: sadə, lakin «pəncərə keçid» həssasdır.
Sliding window: daha dəqiq, lakin daha bahalı hesablama.

2. 4 GCRA (Generic Cell Rate Algorithm)

Virtual gəliş vaxtı baxımından Token Bucket ekvivalenti.
Paylanmış limitlər üçün dəqiq və sabitdir (daha az münaqişə vəziyyəti).

2. 5 Concurrency Limits

Eyni zamanda həyata keçirilən əməliyyatların məhdudlaşdırılması.
Hovuz axınları/bağlantıları və «head-of-line blocking» tükənməkdən qoruyur.

3) Limitlər harada tətbiq olunur

Sərhəddə (L7/API-şlyuz): əsas maneə, sürətli uğursuzluq (429/503), ucuz yoxlamalar.
Xidmətlər daxilində: ağır əməliyyatlar üçün əlavə caps (ixrac, hesabat, transformasiya).
Xarici sistemlərə çıxışda: üçüncü tərəflər üçün fərdi limitlər (anti-penalty).
Növbələrdə/məşqlərdə: ümumi hovuzlara fairness.

4) Satınalmalar və prioritetlər (multi-tenant)

Иерархия: Global → Region → Tenant/Plan → User/Token → Endpoint/Feature → IP/Device.
Priority-aware: VIP/Enterprise daha böyük 'burst' və çəki alır, lakin ümumi SLO qırmaq deyil.
Limitlərin tərkibi: yekun tolerantlıq = 'min (qlobal, regional, tenant, xüsusi, son)'.

5) Həcminə görə kvotalar

Gündəlik/aylıq kvotalar: sənədlər/gün, GB/ay, mesajlar/dəq.
Yumşaq/sərt eşiklər: xəbərdarlıqlar (80/90%) və «sərt stop».
Roll-up: obyektlərin (cədvəllər, fayllar, hadisələr) uçotu və billinqə «çıxarılması».

6) Paylanmış limiterlər

Tələblər: aşağı gecikmə, uyğunluq, uğursuzluğa davamlılıq, üfüqi miqyas.

Local + probabilistic sync: yerli şar kovaları + periodik sinxronizasiya.
Central store: Redis/KeyDB/Memcached с LUA/atomic ops (INCR/PEXPIRE).
Sharding: Növ açarları 'limit: {scope}: {id}: {window}' vahid paylama ilə.
Clock skew: «həqiqəti» müştərilərdə deyil, limiter serverində saxlayın.
İdempotentlik: «əməliyyatların» (Idempotency-Key) açarları saxta silinmələri azaldır.

7) Anti-sui-istifadə və müdafiə

Per-IP + device fingerprint ictimai end-pointlər üçün.
Anomaliyalar zamanı Proof-of-Work/CAPTCHA.
Slowdown (throttling) UX daha vacib olduqda tam imtina əvəzinə (axtarış ipuçları).
Adaptive limits: hadisələrin/bahalı deqradasiyanın dinamik azalması.

8) Müştəri davranışı və protokol

Kodlar: '429 Too Many Requests' (rate), '403' (kvota/plan aşdı), '503' (qoruyucu deqradasiya).

• 'Retry-After: ' - nə vaxt yenidən cəhd etmək olar.

• `RateLimit-Limit: ;w=`
• `RateLimit-Remaining: `
• `RateLimit-Reset: `
• Backoff: eksponensial + jitter (full jitter, equal jitter).
• İdempotentlik: 'Idempotency-Key' başlığı və təhlükəsiz əməliyyatların təkrarlanması.
• Zaman aşımı və ləğv: limitləri «ələ keçirməmək» üçün asılmış sorğuları düzgün şəkildə kəsin.

9) Müşahidə və test

Теги: `tenant_id`, `plan`, `user_id`, `endpoint`, `region`, `decision` (allow/deny), `reason` (quota/rate/concurrency).
Metriklər: bant genişliyi, 429/403/503 nasazlıqlarının nisbəti, limiter gecikmələri p95/p99, açar cache hit ratio, planlar üzrə paylama.
Audit qeydləri: blokların səbəbləri, top «səs-küylü» açarlar.
Testlər: «mişar/burst/plato» yükləmə profilləri, xaos - Redis/shard uğursuzluğu, saatların sinxronizasiyası.

10) Billing ilə inteqrasiya

Usage sayğacları sərhəddə yığılır, idempotentlik ilə batches (hər N dəq) ilə yığılır.
Planların xülasəsi: həddindən artıq → overcharge və ya planın müvəqqəti artırılması.
Uyğunsuzluqlar: usage vs invoice; delta alertlər.

11) Daxili fairness (növbələr, məşqçilər)

Weighted Fair Queuing/DRR: planın çəkisinə görə kirayəçilər arasında slotların paylanması.
Per-tenant worker pools: sərt izolyasiya VIP/səs-küylü.
Admission control: kvotalar tükənsə, yerinə yetirilməmişdən əvvəl; növbələr şişirmir.
concurrency Caps: eyni zamanda ağır jobs məhdudlaşdırmaq.

12) Standart plan profilləri (nümunə)

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) Memarlıq etalonu (şifahi sxem)

1. Edge/API-şluz: TLS → kontekstini çıxarın (tenant/plan) → limitləri/kvotaları yoxlayın → RateLimit- → log/trace başlıqlarını yerləşdirin.
2. Policy Engine: prioritet qaydaları (VIP), adaptiv eşiklər.
3. Limiter Store: Redis/KeyDB (atomic ops, LUA), açar şardlanması, replikasiya.
4. Services: ağır əməliyyatlar üçün ikincil limit və caps; idempotentlik; WFQ/DRR ilə növbələr.
5. Usage/Billing: toplama, aqreqasiya, invoys, həddindən artıq.
6. Observability: metriklər/loqi/treys ilə tagged, dashboard per-tenant.

14) Satış öncəsi yoxlama siyahısı

• Limit scopları (tenant/user/token/endpoint/IP) və onların iyerarxiyası müəyyən edilmişdir.
• Seçilmiş alqoritm (Token Bucket/GCRA) və parametrləri 'rate/burst'.
• Ağır əməliyyatlar üçün concurrency caps və admission control həyata keçirilmişdir.
• 'RateLimit-' və 'Retry-After' başlıqları daxil edilmişdir; müştərilər backoff + jitter dəstəkləyir.
• Limiter paylanmış və uğursuzluğa davamlı (şarlar, replikasiya, deqradasiya).
• Usage-toplama idempotenten; billing ilə bir dəstə, həddindən artıq istehlak üçün risklər.
• Müşahidə: metriklər/treys/log ilə tagged, top «səs-küylü» açarlar, alerter 's.
• Testlər: Burst, «mişar», Store, Clock Skew, soyuq başlanğıc.
• Müştərilər üçün sənədləşdirmə: planlara görə limitlər, 429/Retry-After nümunələri, retrajların ən yaxşı əməliyyatları.
• İstisnalar siyasəti: limitləri müvəqqəti artırmaq üçün necə və nə vaxt.

15) Tipik səhvlər

per-tenant/per-endpoint olmadan qlobal limit - «noisy neighbor» bütün SLO qırır.
Yox 'burst': UX qısa sıçrayışlarda əziyyət çəkir.
Yalnız sabit pəncərədən istifadə → «pəncərə sərhədində ikiqat zərbə».
Jitter → fırtına təkrarları ilə idempotentlik və retras yoxdur.
Limitlər yalnız sərhəddə, xidmətlərdə/növbələrdə caps olmadan → daxili «tıxaclar».
Cavablarda limitlərin əks olunmaması (no 'Retry-After', 'RateLimit-') → müştərilər uyğunlaşmır.
DB OLTP → yüksək gizli və «isti» kilidlərdə limiter vəziyyətinin saxlanması.

16) Sürətli strategiya seçimi

Pik ilə açıq API: Token Bucket + böyük 'burst', RateLimit- başlıqlar, CDN/edge keşi.
Daxili ağır joblar: concurrency caps + WFQ/DRR, admission control.
Üçüncü tərəflərlə inteqrasiya: fərdi çıxış limitləri, tamponlama/retraj.
Multi-tenant SaaS: limitlər iyerarxiyası (global → tenant → user → endpoint), VIP prioritetləşdirmə, aylıq kvotalar.

Nəticə

Yaxşı rate limits və kvotalar platforma və müştəri arasında sistemli bir müqavilədir: resursların dürüst payı, sıçrayışa davamlı, proqnozlaşdırıla bilən SLO və şəffaf billing. Alqoritmləri (Token/GCRA + concurrency caps) birləşdirin, skopların iyerarxiyasını tətbiq edin, başa düşülən başlıqları və metrikləri verin və real trafik profillərinin altındakı sxemləri müntəzəm olaraq yoxlayın - platforma aqressiv yük artımı ilə belə sabit qalır.