rate limiter layihələndirilməsi

1) Niyə rate limiting

Rate Limiting API-nin əlçatanlığını və iqtisadiyyatını qoruyur: fludları, retrajların «burstlarını», credential stuffinqi dayandırır, bahalı əməliyyatları (pul əməliyyatları, hesabat yaratmaq) qoruyur, asılı sistemlərə (BD/provayderlərə) yükü hamarlaşdırır. Yaxşı dizayn ədalət (fairness), gecikmə proqnozlaşdırılması və aydın SLO verir.

Əsas məqsədlər

RPS sabitliyi və arxa tərəfin həddindən artıq yükdən qorunması.
Nəzarət olunan «elastiklik» (burst allowance).
Müştərilərin fərqləndirilməsi (per-istifadəçi/per-təşkilat/per-açar/per-IP/per-region).
Dəyər modeli: müxtəlif əməliyyatlar üçün müxtəlif «qiymətlər».

2) Limit növləri

RPS limitləri: saniyədə/dəqiqədə sorğular.
Kvotalar: ümumi büdcə (gün/ay).
Rəqabət: eyni vaxtda əməliyyatlar (checkout, heavy job).
Sürət/zolaq: bayt/san (yükləmə/boşaltma).
Balanslaşdırılmış limitlər: mürəkkəbliyə görə sorğunun «dəyəri» (məsələn, GraphQL complexity, batch ölçüsü).
Adaptiv: anomaliyalar zamanı sərtləşdirilir (şübhəli fəaliyyət/401/403/5xx səhvləri).

3) Alqoritmlər və onları nə zaman tətbiq etmək

3. 1 Fixed window counter

Sadə: interval üçün sayğac (məsələn, 100 r/min).
Üstünlüklər: minimum qiymət. Mənfi cəhətləri: pəncərə sərhədlərində «kənar berstlər».

Nə zaman: admin panelləri, aşağı dəqiqlik, aşağı qiymət.

3. 2 Sliding window (log / counter)

Log: Son sorğuların vaxt etiketlərini saxlayır, dəqiq, yaddaşda əzizdir.
Counter: iki qonşu pəncərə (rolling), dəqiqlik və qiymət kompromis orta.

Nə zaman: ictimai orta trafik API, mürəkkəb riyaziyyat olmadan hamarlığı lazımdır.

3. 3 Token bucket

Parametrlər: 'r' (token/san) sürəti və 'b' (burst) tutumu. Hər sorğu «yandırır» token.
Artıları: təbii burst allowance, sadə həyata. Mənfi cəhətləri: Ciddi bərabərlik yoxdur.

Nə zaman: demək olar ki, həmişə RPS üçün, əgər «yaylım» 'b' daxilində lazımdır.

3. 4 Leaky bucket (drip)

Sabit sürətlə «sızan» növbə.
Üstünlüklər: bərabər çıxış axını. Mənfi cəhətləri: daha çox gecikmə.

Nə zaman: xarici «kövrək» provayderlərə hamarlamaq.

3. 5 GCRA (Generalized Cell Rate Algorithm)

• 'TAT _ next = max (TAT_current, now) + 1/r', əgər 'now <= TAT_current + burst/r'.
• Üstünlüklər: ciddi, dəqiq, az yaddaş (açar TAT saxlamaq). Mənfi cəhətləri: anlamaq daha çətindir.

Nə zaman: ciddi nəzarət və hamarlığa, paylanmış limitlərə ehtiyac var.

3. 6 Rəqabətli semaforlar

Aktiv əməliyyatlar sayğacı; giriş - «biletlər» varsa; çıxış - azad.
Nə zaman: long-running əməliyyatları, axınlar, WebSocket, downloads.

4) Limit açarları modeli

• `client_id`/`api_key`/`user_id`/`org_id`
• 'IP/ASN/geo' (kobud müdafiə)
• 'endpoint/method' (isti marşrutlar)
• 'scope/plan/tier' (monetizasiya)
• 'idempotency _ key' (write-əməliyyatlar)
• Hiyerarxiyadan istifadə edin: əvvəlcə ciddi per-key, sonra per-təşkilat, sonra qlobal.

5) Tələb çəkisi (cost model)

• GraphQL: sahələrdə çətinlik × dərinlik.
• REST: cavab/sorğu ölçüsü, əməliyyat növü (read = 1, write = 3, hesabat = 10).
• Batch: `cost = min(n, cap)`.
• «Sorğular» deyil, tokenləri məhdudlaşdırırıq: 'budget - = cost (q)'.

6) Paylanmış satış

6. 1 Anbarlar

In-process: ultra sürətli, lakin ümumi limit deyil (yerli «yumşaq» limitlər üçün uyğundur).
Redis: de-fakto standart. INCR/EXPIRE, Lua skriptləri (atom), sliding window üçün ZSET, TTL ilə açarlar.
Envoy/NGINX/Kong/Traefik: daxili filtrlər; perimetri üçün əlverişlidir.
Service Mesh: sidecar + qlobal sinxronizasiya üzrə lokal limitlər.

6. 2 Atomizm və yarış

Redis Lua: bir addım yoxlama və inklement.
GCRA: CAS/script ilə bir TAT saxlamaq.
Saat uyğunluğu: NTP, monoton zamanlayıcılar.
Sharding: açar hash; «isti» şardlardan çəkinin.

6. 3 Geoayrılması

Regional klasterlərdə lokal limitlər + üst qlobal (coarse).
CRDT/replikasiya - ehtiyatlı (gecikmələr, ikiqat sərf). Ehtiyatla regional limitlərə üstünlük verilir.

7) Siyasət və prioritetləşdirmə

Planlar: Free/Pro/Enterprise müxtəlif 'r', 'b', kvotalarla.
Prioritetlər: «bahalı» marşrutlar daha kiçik limit və ya daha böyük cost alır.
Siyahılar: inteqrasiya üçün allow-list, ASN/proxy/TOR tərəfindən deny.
Eskalasiya: təkrar aşdıqda - limiti aşağı salırıq, proof-of-work/kapça/çağırış tətbiq edirik.

8) Konfiqurasiya nümunələri

8. 1 Envoy (HTTP rate limit filter, psevdo)

yaml rate_limit:
domain: public-api descriptors:
- key: api_key rate_limit:
unit: second requests_per_unit: 50 burst: 100
- key: api_key value: payments. write rate_limit:
unit: second requests_per_unit: 5 burst: 10

8. 2 NGINX (lua + Redis, psevdo)

nginx lua_shared_dict limits 10m;

location /api/ {
access_by_lua_block {
local key = ngx. var. arg_apikey.. ":".. ngx. var. request_method.. ":".. ngx. var. uri
-- token bucket in Redis (evalsha)
local allowed, retry_after = ratelimit_allow(key, 50, 100) -- r=50/s, b=100 if not allowed then ngx. header["Retry-After"] = retry_after return ngx. exit(429)
end
}
proxy_pass http://backend;
}

8. 3 Rəqabət limitləri (psevdokod)

pseudo on_request_start(key):
if redis. incr_with_ttl("sem:" + key, ttl=60) > MAX_CONCURRENCY:
redis. decr("sem:" + key); reject(429)
on_request_finish(key):
redis. decr("sem:" + key)

8. 4 GCRA (psevdokod)

pseudo params: r tokens/sec, burst b tat = redis. get(key) or now allowed_time = tat - (b / r)
if now < allowed_time: reject(429, retry_after = allowed_time - now)
tat_next = max(tat, now) + 1/r redis. set(key, tat_next, ttl = ceil(b/r) + safety)

9) Retras, taymaut və circuit breaker ilə inteqrasiya

Retry-budget: retrajların payını əsas trafikin X% -ə qədər məhdudlaşdırın.
Jitter: backoff ilə həmişə jitter əlavə edin - sinxron sıçramaları azaldır.
Circuit breaker: yüksək səhv olduqda ('5xx', timeouts) limitləri azaltın və ya marşrutların bir hissəsini «read-only» -ə köçürün.
Hedging: diqqətlə; büdcə xərclərini iki dəfə artırmamaq üçün cost-u nəzərə alın.

10) Müşahidə və nəzarət

Метрики: `rps_allowed`, `rps_blocked`, `429_rate`, `retry_after_avg`, `burst_used`, `quota_remaining`, `active_concurrency`.
Etiketlər: limit açarı, region, end-point, plan.
Həllərin qeydləri (sample): uğursuzluq səbəbi, cari sayğaclar, TTL açarı.
Dashbord: açar/end-point istilik kartları, «isti» müştərilər.
Alertlər: kritik marşrutlarda artım 429> 2-5%, tez-tez kvotaların «tükənməsi», şard balanssızlığı.

11) Test və validasiya

Siyasətçilərin müqavilə testləri («əgər» cədvəlləri).
Yükləmə: burstlar (x10 r), uzun platolar, «çirkli» nümunələr (slow-POST, uzun birləşmələr).
Chaos trafik: qeyri-bərabər axınlar, clock drift, Redis/mesh.
A/V-daxil: canary rollout limitləri, shadow-həllər (loqo, lakin bloklama) başlamazdan əvvəl.

12) Edge cases və incəliklər

Clock skew: Müştəri başlıqlarından deyil, vahid mənbədən (server) 'now ()' istifadə edin.
Idempotency-Key: write üçün - retralarda amplifikasiyanı azaldır.
Batch əməliyyatları: batch ölçüsü və ümumi cost ilə məhdudlaşdırın.
Long-poll/WebSocket: kanalların/abunələrin sayına və müddətinə görə məhdudlaşdırın.
Cold start: «isti» sayğacların başlanğıcı/əvvəlcədən yüklənməsi; əks halda yalançı sıçrayışlar 429.
Hesablama baxımından bahalı sorğular: biznes məntiqini həyata keçirməzdən əvvəl məhdudlaşdırın.
TTL sərhədləri: TTL açarları pəncərə + ehtiyat (safety margin) əhatə etməlidir.

13) Antibot eskalasiyası

Addımlar: xəbərdarlıq → 429 + 'Retry-After' → challenge (kapça/bulmaca) → müvəqqəti blok.
Siqnallar: device-fingerprint, kursor davranışı/tayminqlər, TOR/proxy/hostinqlər.
Siyasətçilər müəyyən edilməli və forensika üçün təkrarlanmalıdır.

14) Təhlükəsizlik və uyğunluq

Kritik marşrutlarda Deny-by-default (write/maliyyə).
Audit: tənzimləmə halları və hadisələrin təhlili üçün limit qərarlarını saxlayın.
PII: Limitlərin açarları qeydlərdəki şəxsi məlumatları açıqlamamalıdır.

15) Prod hazırlıq yoxlama siyahısı

• Limit açarları və cost modeli müəyyən edilmişdir.
• Alqoritm (token bucket/GCRA) və saxlama (Redis/şlyuz) seçilmişdir.
• Müştərilər üçün siyasətlər + qlobal «qoruyucular».
• Uzun əməliyyatlar üçün rəqabət limitləri.
• Retry-budget, jitter ilə backoff, circuit breaker ilə inteqrasiya.
• Dashboard/Alerts, Sample log həllər.
• Canary-daxil və shadow-rejimi.
• Burst testləri, uzun platolar, Redis uğursuzluqları, clock skew.
• Müştərilər üçün sənədləşmə: 429 kodları, 'Retry-After', eksponent backoff nümunələri.

16) TL; DR

Redis/Gateway ilə token bucket və ya GCRA istifadə edin, limit açarlarını və sorğu xərclərini layihələndirin, uzun əməliyyatlar üçün rəqabətli semaforlar əlavə edin, retry-budget və circuit breaker ilə inteqrasiya edin, 429 və «burst-tutumu» izləyin, limitləri canary/shadow vasitəsilə yuvarlayın və mütləq test edin burstlar və saxlama nasazlığı.