rate limiter 'дерді жобалау

1) Неге rate limiting

Rate limiting API қолжетімділігі мен экономикасын қорғайды: флудаларды, ретрайлардың «бурсттарын», credential stuffing тоқтатады, қымбат операцияларды (ақша транзакцияларын, есептер генерациясын) қорғайды, тәуелді жүйелерге (ДҚ/провайдерлерге) жүктемені жұмсартады. Жақсы дизайн әділдікті (fairness), жасырындылықты болжауды және айқын SLO береді.

Негізгі мақсаттар

RPS тұрақтылығы және бэкендті шамадан тыс жүктемеден қорғау.
Басқарылатын «икемділік» (burst allowance).
Клиенттерді саралау (пер-пайдаланушы/пер-ұйым/пер-кілт/пер-IP/пер-өңір).
Құндық модель: әртүрлі операциялар үшін әртүрлі «бағалар».

2) Лимиттердің түрлері

RPS шектері: секундына/минутына сұраулар.
Квоталар: кезеңдегі жиынтық бюджет (күн/ай).
Бәсекелестік: бір мезгілде жасалатын операциялар (checkout, heavy job).
Жылдамдық/жолақ: байт/сек (тиеу/түсіру).
Өлшенген лимиттер: күрделілігі бойынша сұрау салудың «құны» (мысалы, GraphQL complexity, batch мөлшері).
Бейімделгіш: аномалиялар кезінде қатаңдатылады (күдікті белсенділік/қателер 401/403/5xx).

3) Алгоритмдер және оларды қашан қолдану

3. 1 Fixed window counter

Қарапайым: аралыққа есептегіш (мысалы, 100 r/min).
Артықшылықтары: ең төменгі құны. Кемшіліктері: терезе шекарасындағы «шеткі берстер».

Қашан: әкімші панелі, жоғары дәлдігі, төмен құны.

3. 2 Sliding window (log / counter)

Log: соңғы сұраулардың уақыт белгілерін сақтайды.
Counter: көршілес екі терезенің ортасы (rolling), дәлдік пен баға ымырасы.

Қашан: орташа трафиктің ашық API, күрделі математикасыз тегістілік қажет.

3. 3 Token bucket

Параметрлері: 'r' (токендер/сек) жылдамдығы және 'b' (burst) сыйымдылығы. Әрбір сұрау токенді «өртейді».
Артықшылықтары: табиғи burst allowance, қарапайым іске асыру. Кемшіліктері: қатаң біркелкілік жоқ.

Қашан: 'b' шегінде «соқпақтар» қажет болса, RPS үшін әрқашан дерлік.

3. 4 Leaky bucket (drip)

Белгіленген жылдамдықпен «ағып кететін» кезек.
Артықшылықтары: тегіс шығу ағыны. Кемшіліктер: көп кідірістер.

Қашан: сыртқы «нәзік» провайдерлерге тегістеу.

3. 5 GCRA (Generalized Cell Rate Algorithm)

• 'TAT _ next = max (TAT_current, now) + 1/r', егер 'now <= TAT_current + burst/r' болса, сұрау қабылданды.
• Артықшылықтары: қатаң, дәл, жады аз (кілт бойынша TAT сақтаймыз). Кемшіліктері: түсіну үшін қиын.

Қашан: қатаң бақылау және бірқалыптылық, бөлінген лимиттер қажет.

3. 6 Бәсекелес семафорлар

Белсенді операцияларды есептегіш; кіру - егер «билеттер» болса; шығу - босату.
Қашан: long-running операциялары, ағымдар, WebSocket, жүктеулер.

4) Лимиттер кілттерінің моделі

• `client_id`/`api_key`/`user_id`/`org_id`
• 'IP/ASN/гео' (өрескел қорғау)
• 'endpoint/method' (ыстық бағыттар)
• 'scope/plan/tier' (монетизация)
• 'idempotency _ key' (write-операциялар)
• Иерархияны пайдаланыңыз: алдымен қатаң пер-кілт, содан кейін пер-ұйым, содан кейін жаһандық.

5) Сұрау салмағы (cost model)

• GraphQL: өрістердің күрделілігі × тереңдігі.
• REST: жауап/сұрау мөлшері, операция түрі (read = 1, write = 3, есеп = 10).
• Batch: `cost = min(n, cap)`.
• «Сұраулар» емес, токендерді шектейміз: 'budget - = cost (q)'.

6) Бөлінген іске асыру

6. 1 Сақтау орны

In-process: ультра жылдам, бірақ жалпы лимит емес (жергілікті «жұмсақ» лимиттер үшін жарамды).
Redis: де-факто стандарт. INCR/EXPIRE, Lua-скрипттер (атомарлық), sliding window үшін ZSET, TTL кілттері.
Envoy/NGINX/Kong/Traefik: кіріктірілген сүзгілер; периметрге ыңғайлы.
Service Mesh: sidecar + жаһандық синхрондау үшін жергілікті лимиттер.

6. 2 Атомарлық және жарыс

Redis Lua: тексеру және бір адымда инкремент.
GCRA: CAS/скрипті бар бір TAT сақтау.
Сағат үйлесімділігі: NTP, монотонды таймерлер.
Sharding: кілт бойынша консистентті хеш; «ыстық» шардардан аулақ болыңыз.

6. 3 Геораспределение

Өңірлік кластерлердегі жергілікті лимиттер + жоғарғы жаһандық (coarse).
CRDT/репликация - абайлап (кідірістер, екі есе шығын). Өңірлік лимиттер артықшылықты.

7) Саясат және басымдық беру

Жоспарлар: Free/Pro/Enterprise түрлі 'r', 'b', квоталармен.
Басымдықтар: «қымбат» маршруттар аз лимит немесе үлкен cost алады.
Тізімдер: интеграцияға арналған allow-list, ASN/прокси/TOR бойынша deny.
Эскалация: қайта артқан кезде - лимитті төмендетеміз, proof-of-work/капчу/челленджи енгіземіз.

8) Конфигурация мысалдары

8. 1 Envoy (HTTP rate limit filter, псевдо)

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, жалған)

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 Бәсекелестік лимиттер (жалған құжат)

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 (жалған құжат)

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) Ретралармен, таймауттармен және circuit breaker интеграциясы

Retry-budget: негізгі трафиктің X% -ына дейін ретра үлесін шектеңіз.
Jitter: backoff кезінде әрқашан джиттерді қосыңыз - синхронды жарылыстарды азайтады.
Circuit breaker: жоғары қателікте ('5xx', timeouts) лимиттерді төмендетіңіз немесе маршруттардың бір бөлігін «read-only» деп аударыңыз.
Hedging: ұқыпты; бюджет шығынын екі еселемеу үшін cost ескеріңіз.

10) Бақылау және басқару

Метрики: `rps_allowed`, `rps_blocked`, `429_rate`, `retry_after_avg`, `burst_used`, `quota_remaining`, `active_concurrency`.
Лейблдер: лимит кілті, өңір, эндпоинт, жоспар бойынша.
Шешімдердің логтары (жинақталған): істен шығу себебі, ағымдағы есептегіштер, кілттің TTL.
Дашбордтар: кілттер/эндпоинттер бойынша жылу карталары, «ыстық» клиенттер.
Алерттар: шекті бағыттардағы өсім 429> 2-5%, квоталардың жиі «таусылуы», шардтардың теңгерімсіздігі.

11) Тестілеу және валидация

Саясаттың келісімшарттық тестілері («егер болса» кестелері).
Жүктелетін: бурсттар (x10-дан r), ұзақ платолар, «лас» паттерндер (slow-POST, ұзақ қосылыстар).
Chaos-трафик: біркелкі емес ағындар, clock drift, Redis/mesh.
А/В-қосу: қосу алдында canary rollout лимиттері, shadow-шешімдер (логиндік, бірақ блоктамаймыз).

12) Edge-кейстер және нәзіктік

Clock skew: 'now ()' дегенді клиент тақырыптарынан емес, бір көзден (сервер) пайдаланыңыз.
Idempotency-Key: write үшін - ретра кезінде amplification азайтады.
Batch-операциялар: батч өлшемі бойынша және жиынтық cost бойынша лимиттеңіз.
Long-poll/WebSocket: арналар/жазылымдар саны және ұзақтығы бойынша шектеңіз.
Cold start: есептегіштерді «жылы» бастау/алдын ала жүктеу; әйтпесе жалған жарылыстар 429.
Өте қымбат сұраулар: бизнес-логиканы орындағанға дейін шектеңіз.
TTL шектері: TTL кілттері терезені + қорды (safety margin) жабуы тиіс.

13) Анти-эскалация

Сатылар: ескерту → 429 + 'Retry-After' → challenge (капча/пазл) → уақытша блок.
Сигналдар: device-fingerprint, меңзердің мінез-құлқы/таймингтер, TOR/прокси/хостингтер.
Саясаткерлер форензия үшін детерминирленген және қайталанатын болуы тиіс.

14) Қауіпсіздік және комплаенс

Сындарлы бағыттардағы Deny-by-default (write/қаржы).
Аудит: реттеуші жағдайлар мен инциденттерді талдауға арналған лимиттер бойынша шешімдерді сақтаңыз.
PII: лимиттердің кілттері логтардағы дербес деректерді ашпауы тиіс.

15) Prod-дайындық чек-парағы

• Лимиттердің кілттері және cost-модель анықталды.
• Алгоритм (token bucket/GCRA) және сақтау орны (Redis/шлюз) таңдалды.
• Клиенттерге арналған саясат + жаһандық «сақтандырғыштар».
• Ұзақ операциялар үшін бәсекелестік лимиттер.
• Retry-budget, джиттермен backoff, circuit breaker-мен интеграция.
• Дашбордтар/алерттар, шешімдердің сэмплирленген логтары.
• Canary қосу және shadow режимі.
• Бурст, ұзақ плато, Redis, clock skew сынақтары.
• Клиенттерге арналған құжаттама: 429, 'Retry-After' кодтары, экспоненциалдық backoff мысалдары.

16) TL; DR

Redis/шлюзі бар token bucket немесе GCRA пайдаланыңыз, лимит кілттерін және сұрау құнын жобалаңыз, ұзақ операциялар үшін бәсекелес семафорларды қосыңыз, retry-budget және circuit breaker-мен біріктіріңіз, 429 және «бурст-сыйымдылықты» қадағалаңыз, лимиттерді canary/shadow арқылы жаю және міндетті түрде тестілеу қойманың бурсттары мен істен шығуы.