Rate Limits және жүктемені бақылау

TL; DR

Сенімді контур - бұл бірнеше деңгейдегі лимиттер мен квоталардың комбинациясы (edge → BFF → сервис), ресурстарды әділ бөлу (per-tenant/кілт/роут), үнсіз тайм-ауттардың орнына SLO-бейімделген троттлинг және бэкпрешер. «Жылдамдық» үшін token/leaky bucket, бухгалтерлік квоталар үшін жылжымалы терезені, ауыр операциялар үшін бәсекелестік лимиттерді, деградация кезінде dynamic throttling және нәзік апстримдерге circuit-breaker пайдаланыңыз. Барлығы бақылауда және плейбукпен.

1) Неге iGaming/fintech лимиттері

SLO және тұрақтылық: ретрайлардың көшкіндерінен, турнирлердің/эвенттердің шыңдарынан, төлемдердің жарылуынан қорғау.
Әділеттілік: бір тенант немесе серіктес бүкіл бюджетті «сорып алмайды».
Антиабьюз/боттар: логин/тіркеу, спам, скрейпинг каталогтарының дорилимитингі.
Құны: қымбат шақыруларды тежеу (KYC, есептер, агрегациялар).
Комплаенс/адал пайдалану: шарттардағы ресми «fair use» квоталары.

2) Лимиттердің таксономиясы

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

3. 1 Token Bucket (әдепкі)

Параметрлері: 'rate' (токендер/сек), 'burst' (макс қор).
API оқу, төлем/мәртебелер, BFF үшін тамаша.
Бос бакет кезінде → 429 + 'Retry-After'.

3. 2 Leaky Bucket (орташаланған)

RPS кепілдендірілген «бұзу» вебхуктар үшін воркерлерді толтырмау үшін пайдалы.

3. 3 Fixed Window vs Sliding Window

Fixed - қарапайым, бірақ «шектер»; Sliding - шынайы терезе есебі (мин/сағ/тәулік).
Келісімшарттық квоталар үшін Sliding қолданыңыз.

3. 4 Concurrent Limits

Бір мезгілде белсенді тапсырмалар лимиті. Экспорт/репортаж, KYC-пакеттер, қайта өңдеу үшін тамаша.
Жетіспеген жағдайда - 429/503 + кезек/поллинг.

3. 5 Cost/Complexity Limiter

GraphQL/іздеу: тереңдігі/түбегейлілігі/кеңеюі бойынша «құнын» санаймыз.
«Қымбат» сұрауларды ажырату/деградациялау, көмекпен жауап беру.

4) Лимиттеу кілттері (dimensioning)

per-tenant (мультиаренда, әділдік),

per-api_key/client_id (әріптестер),

per-route (қатты сыни мутациялар),

per-user/device/IP/ASN/geo (антидот/антискрейп),

per-BIN/country (төлем әдістері, эмитенттер мен провайдерлерді қорғау),

per-method (GET жұмсақ, POST/PUT қатал).

Композиция: негізгі кілт + «тәуекел мультипликаторы» (жаңа аккаунт, TOR/прокси, жоғары chargeback-тәуекел).

5) SLO-бейімделетін троттлинг

• Триггерлер: 'p95 latency ↑', '5xx ↑', 'queue len ↑', 'CPU/IO saturation'.
• Әрекеттер: rate/burst төмендету, outlier-ejection қосу, «қымбат» роуттарды қысқарту, уақытша degrade (ауыр өрістерсіз/агрегациясыз).
• Қайтару: қатарынан N интервал сигналдарын қалыпқа келтіру кезінде сатылы (25 → 50 → 100%).

6) Сәулетке кірігу

API Gateway (edge): бастапқы rate/quotas, гео/ASN, HMAC/JWT-валидация, 429/' Retry-After '.
BFF/Service Mesh: жіңішке per-route/per-tenant лимиттері, concurrent-limits, circuit-breakers апстримдерге.
Сервис ішінде: ауыр оталарға арналған семафорлар, кезектегі бэкпрешер, bound өлшемді «жұмыс пулдары».
Вебхактар: leaky bucket және ретра буфері бар жеке ingress-эндпоинт.

7) Конфигурациялар (фрагменттер)

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 }

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% }

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()

pseudo cost = sum(weight(field) cardinality(arg))
if cost > tenant. budget then reject(429,"query too expensive")

8) Әртүрлі арналарға арналған саясат

REST

GET - жұмсақ, POST/PATCH/DELETE - қатал; «іспеттес» мәртебелерді/тексерулерді ретрациялауға болады.
Төлемдер үшін: 'auth/capture/refund' per-user/tenant/BIN/еліне лимиттер.

GraphQL

Depth/complexity caps, persisted/whitelisted queries, «алиастарға» арналған лимиттер.

WebSocket/SSE

'subscribe/unsubscribe' жиілік шегі, 'policy _ disconnect' толған кезде топиктер санына, оқиғалар өлшемін бақылау және send-queue → қапшығы.

Вебхактар

Leaky bucket қабылдау, per-sender квоталар, dead-letter кезек, детерминирленген 2xx/429.

9) Клиенттерге кері байланыс

• `Retry-After: `
• `X-RateLimit-Limit/Remaining/Reset`
• Квоталар үшін - 403 'quota _ exceeded' кодымен және жоспарды жаңарту сілтемесімен.
• Құжаттама: OpenAPI/SDL + «Fair Use» беттеріндегі лимиттер.

10) Мониторинг және дашбордтар

• 'rate. limit. hit 'кілттер/роуттар/тенанттар бойынша.
• 429/503 доля, latency p50/p95/p99, error rate, queue length, open circuits.
• Fair-share: тұтыну бойынша топ-тенанттар, «bully detector».
• Вебхактар: қабылдау/ретраи, drop-rate, орташа лаг.

• 429 жалпы RPS-тен 1-3% артық емес (ботсыз).
• p95 лимитерді қосу ≤ edge-ге 5-10 мс.
• Деградациядан кейін қалпына келтіру уақыты ≤ 10 минут.

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) Инциденттердің плейбуктері

Дауыл ретрайлары (апстримнің құлдырауы): global throttling қосыңыз, backoff көтеріңіз, circuit-breaker ашыңыз, тайм-ауттың орнына «жылдам қателерді» қайтарыңыз.
Бот-шабуыл/скрейпинг: IP/ASN/гео бойынша қатты кап, WAF/JS-челлендж қосу, каталогтарды/іздеуді шектеу.
Турнир/эвенттің шыңы: алдын ала оқу лимиттерін көтеру, «қымбат алаңдарды» төмендету, кэш/денормализацияны қосу.
PSP веб-хоктарын тарату: уақытша leaky bucket, сыни түрлерді басымдыққа алу, dead-letter және ретрацияны кеңейту.

12) Тестілеу және UAT

Жүктеме: RPS баспалдақ, қалыпты × 10 бурсты.
Әділеттілік: 1 «ач» тенанттың эмуляциясы - жаһандық бюджеттің X% -нан аспайды.
Деградация: SLO-бейімделу лимиттерді қысқартады және p95 дәлізде ұстайды.
Шекті кейстер: терезені ауыстыру (мин → сағ), сағаттың дірілдеуі (clock skew), Redis масштабтау/кілттердің шардингі.
Келісімшарт: 429 және Retry-After тақырыптары бар, SDK дұрыс бэк-оффит.

13) Лимиттерге арналған қойма

Жергілікті лимиттер үшін In-memory (шағын кластерлер).
Таратылғандарға арналған Redis/Memcached (атомарлық үшін Lua скрипттері).
Кілттерді хэш бойынша шардалау; TTL терезенің астында; кэшті жоғалтуға арналған бэкап-метрика.
Idempotency: лимитер қайталама қоңырауларды бұзбауы керек (сұрау кілті бойынша есеп).

14) Саясатты басқару (Governance)

Лимиттер каталогы: кім иеленеді, қандай кілттер/табалдырық/рационал.
Жылдам ауыстырып қосқыштар үшін Feature-flags (crisis mode).
Келісімшарттық квоталарды өзгерту саясаты мен RFC-процесін нұсқалау.
A/B оңтайлы шектерді таңдауға арналған эксперименттер.

15) Қарсы үлгілер

Жаһандық бір лимит «барлық API».
Тек бекітілген терезелер → «шеткі» секірістер.
Кері байланыссыз лимит (жоқ 'Retry-After '/headers).
Жылдам 429/503 орнына үнсіз тайм-ауттар.
per-tenant fair-share болмауы - бір клиент қалғандарын тұншықтырады.
GraphQL/іздеу қорғанысы жоқ.
Нөлдер concurrent-guard → «шаңсорғыш» ДБ/PSP.

16) Шағын шпаргалка таңдау

Әдепкі: token bucket (rate + burst) per-tenant + route.
Ақша/есептер бойынша квоталар: sliding window тәулік/ай.
Ауыр операциялар: concurrent-limits + кезек.
GraphQL/поиск: complexity-budgets + persisted queries.
WS/вебхактар: leaky bucket + backpressure.
Кризис: dynamic throttling + circuit-breaker + degrade.

Түйіндеме

Жүктемені бақылау - бұл көп деңгейлі тәртіп: дұрыс алгоритмдер (bucket/терезе/бәсекелестік), әділ лимиттеу кілттері, SLO-бейімделу және ашық кері байланыс. gateway/mesh/сервистерге шектеулер тігіп, GraphQL/WS/вебхоктарды профильді полистермен жарақтандырып, плейбуктермен бақылау мүмкіндігін қосу арқылы сіз ең жоғары оқиғаларды және басқалардың істен шығуларын басқарылатын жағдайға айналдырасыз - бояусыз, бұзылған төлемдерсіз және конверсияланбайды.