Лимит иерархиясы

Лимит - бұл операцияны уақыт/көлем/құн бойынша формалдандырылған шектеу. iGaming пен финтехте лимиттер - қауіпсіздіктің, реттеулерге сәйкестіктің және тәуекелдерді басқарудың негізі. Лимиттер иерархиясы екi есе шығынға, ставкалардың/депозиттердiң асып кетуiне, бонустарды терiс пайдалануға және жауапты ойындарды бұзуға жол бермеу үшiн кiмнiң ережесi басым және ол қайда орындалатынын анықтайды.

1) Лимиттерді жіктеу

Қолданылу күшіне қарай

Hard - еңсерілмейтін (операцияларға тыйым салу).
Soft - ескерту/фрикция (капча, растау), қайталау кезінде hard дейін эскалация.

Табиғат бойынша

Ақшалай: депозит сомасы/ставкалар/төлемдер; күндізгі/апталық/айлық шектер.
Уақытша: сессияның ұзақтығы, үзілістер, «салқындату», тайм-ауттар.
Сандық: транзакциялар, спиндер, API сұраулар саны.
Жылдамдық (rate limits): RPS/бәсекелестік.
Квоталар: терезе үшін іс-қимыл бюджеті (тәулігіне/аптасына N).
Контекст: ойын/провайдер/төлем әдісі/құрылғы/ел бойынша.

Иесі бойынша

Реттеуші/брендтік (тенант/өңір)

Жүйелік (платформа, инфрақұрылымды қорғау)

Пайдаланушылар (RG шеңберінде self-limits)

2) Өлшеу және кілттер (scoping)

tenant_id · region · license · currency · channel · brand player_id · kyc_tier · rg_state · age game_id · provider_id · product (casino/sports/live)
payment_method · device_fingerprint · ip_asn

Кілт неғұрлым дәл болса, басымдық соғұрлым жоғары болады (иерархияны төменде қараңыз).

3) Иерархия және басымдықтар (most specific wins)

GLOBAL_DEFAULT
< TENANT/BRAND
< REGION/LICENCE
< PRODUCT/PROVIDER/GAME
< CURRENCY/CHANNEL/PAYMENT_METHOD
< PLAYER (KYC/RG)
< SESSION/DEVICE
<REQUEST (idempotency-key operation)

• Неғұрлым жіңішке мәтінмәні кең: player> region.
• Кез келген айқын deny allow жеңеді.
• soft/hard қайшылықтары hard пайдасына шешіледі.
• Мерджа квоталар/терезелер кезінде ең төменгі рұқсат етілген мән (min-cap) жеңеді.

4) Деректер моделі (оңайлатылған)

sql
CREATE TABLE limits (
id      bigserial primary key,
scope jsonb, -- context keys (tenant, region, player_id,...)
kind     text,     -- bet_amount, deposit_daily, rps_api, payout_single, session_duration type     text,     -- HARD      SOFT      QUOTA     RATE value numeric, -- sum/qty/seconds/ops window_sec int, -- for QUOTA/RATE, else null burst int, -- for RATE token-bucket currency text, -- if applicable reason_code text, -- regulator/product/security valid_from timestamptz,
valid_to   timestamptz,
priority int default 0, -- manual specificity overlide created_by text,
created_at  timestamptz default now()
);

CREATE TABLE limit_counters (
key_hash   text primary key,  -- hash(scope,kinda,window_start)
window_start timestamptz,
consumed numeric, -- money/pcs/sec updated_at timestamptz
);

Теңсіздік: барлық операциялар 'operation _ id'; есептеуіш инкремент бір рет орындалады (нұсқасы бойынша inbox/outbox немесе compare-and-swap).

5) Бағалау алгоритмі (evaluation)

1. 'kind' және 'scope' қиылысы бойынша кандидаттарды жинау.
2. Ерекшелігі бойынша ранжирлеу (сәйкес келетін өлшемдер саны) және 'priority'.
3. Мердж параметрлері: қаттылық (hard> soft), min-cap, min-window.
4. Квоталарды/рейт-лимитті тексеру: токен-бакет (RATE) + фикс/жылжымалы терезе (QUOTA).
5. Решение: `ALLOW | SOFT_WARN | DENY` + `retry_after`/`remaining`.
6. Іздің жазылуы: оқиғаның және метриканың аудиті.

json
{
"decision":"DENY",
"kind":"deposit_daily",
"remaining":0,
"window_reset_at":"2025-10-31T21:00:00Z",
"matched_limit_id":12345,
"policy":"REGULATORY",
"reason":"DAILY_CAP_REACHED"
}

6) Қолдану нүктелері (enforcement points)

API Gateway - инфрақұрылымды қорғау: RATE (RPS), CONCURRENCY, burst.
Домендік сервистер - мағыналық лимиттер: депозиттер, мөлшерлемелер, төлемдер, сессиялар.
Провайдерлік адаптерлер - провайдерлердің қайталанатын/жергілікті лимиттері (шақырғанға дейін валидациялау).
Клиенттік UX - алдын алу кеңестері (SOFT), «N қалды», таймерлер.

Ереже: бір рет квота/токендерді - операция қайтымсыз болған жерде (әмиян/валидті аутентификацияланған қадамды резервтегеннен кейін) есептен шығарамыз.

7) Ақша лимиттері: депозит/ставка/төлем

Per currency: FX арқылы емес, операция валютасында лимиттерді сақтаңыз.
Min/Max: `min_bet`, `max_bet`, `max_payout_single`.
Терезелер: белгіленген шекаралары бар 'deposit _ daily/weekly/monthly' (мысалы, лицензия таймзонында).
Композиция: қорытынды рұқсат етілген диапазон = қиылысу (өңірлік ∩ брендтік ∩ пайдаланушылық).

8) Жауапты ойын (RG)

Self-limits (ойыншы өзі қойған) әрқашан брендке қарағанда қатаңырақ.
Уақытша шектеулер: 'session _ duration', 'cool _ off', 'self _ exclusion'.
Эскалация: soft-лимитін арттыру → ескерту, қайталау → hard (терезе шеңберінде).
Аудит: RG-ның әрбір өзгерісі жойылмай тіркеледі (кім/қашан/неліктен).

9) Rate limit vs Quota: қашан не

Rate limit (token-bucket/leaky): жарылыстан қорғау; gateway/адаптерлерде қолдану.
Quota (fixed/sliding window): іс-әрекеттердің/ақшаның жиынтық бюджетін басқару; доменде қолдану (deposit_daily, bet_count_hourly).
Жиі бірге пайдаланылады: 'RATE' (жедел шыңдар) + 'QUOTA' (тәуліктік бюджет).

10) Мульти-тенант және мульти-өңір

Лимиттерде әрқашан 'tenant _ id' және 'region/licence' бар.
Residency: есептегіштер және сақтау - «үй» аймағында.
Fairness: RATE/QUOTA per tenant пулдарын бөліңіз, «шулы» басқалардың SLO-сын бұзбау үшін.

11) Идемпотенттілік және консистенттілік

'operation _ id' командасы; қайталау 'consumed' үлкейтілмеуі керек.
Ақша үшін - strict path: әмиян резерві және бір транзакциядағы/сағаттағы инкремент counters (TCC).
RATE үшін - ағымдағы терезенің атомарлық инкременттерін/қоймаларын пайдаланыңыз.

12) Бақылау

• `limit_eval_p95_ms`, `decision_rate{ALLOW,DENY,SOFT}`,
• 'quota _ remaining _ percent' негізгі түрлері бойынша,
• `rate_throttled`, `burst_dropped`,
• `rg_self_limit_hits`, `regulatory_hits`.

Логи/трейсинг: `matched_limit_id`, `scope_hash`, `operation_id`, `window_start/reset`, `remaining`.

Алерты: 'DENY '/' 429' өсуі табалдырықтан жоғары, реттегіш каптарға жиі қол жеткізу, ойыншы/құрылғы бойынша «hot key».

13) Нұсқалау және аудит

Әр ереже - 'valid _ from/valid _ to', 'created _ by', 'reason _ code'.
События: `LimitCreated/Updated/Deleted`, `LimitHit`, `LimitDenied`.
Тарихи шешімдерді (dispute-ready) ойнату үшін белсенді ережелердің «суретін» сақтаңыз.

14) Тестілеу

Contract tests: ерекшеліктер/басымдықтар схемасы және мердж.
Property-based: «most specific wins», «deny allow», «min-cap».
Golden cases: эталондық жанжалдар жиынтығы (тенант vs өңір, RG vs бренд).
Chaos: сұрау жарылыстары (RATE), есептеуіштер бойынша жарыстар, командаларды қайталау (іспеттілік).
E2E: реттеушінің чек-парақтарындағы лимиттер матчингі (депозит/апта/ай).

15) Ойнатқыштар

1. gateway-те 429/throttling дауылы

Concurrency азайту, токен-бакетті уақытша ұлғайту, сындарлы жолдарға басымдық беру, көздерді талдау (ASN/IP).

2. Реттеуші лимит бойынша жаппай бас тартулар

Терезелер мен таймзонның кестесін тексеру; soft-UX (түсініктемелерді) ұзарту, комплаенсті хабарлау.

3. Жарыс салдарынан жалған-оң істен шығулар

'player _ id/kind' кілті бойынша сериялауды қосу, 'operation _ id' бойынша CAS/дедупқа өту.

4. Провайдерлік лимитпен алшақтық

min/max per game бағдарламасын синхрондау, адаптерге алдын ала валидацияны қосу, ойын каталогын/плейсментін уақытша төмендету.

16) Типтік қателер

Ережелер арасында → «арқанды тарту» иерархиясының болмауы.
UI-дегі лимиттерді серверлік валидациясыз есептеу.
Квоталарды рейт-лимиттермен ауыстыру (және керісінше).
Ақша лимиттері кезінде валюталарды/қадамдарды елемеу (CLP/JPY).
Сәйкессіздік жоқ → квотаны екі рет есептен шығару.
Барлық теңгерімдерге арналған бірыңғай RATE пулы → проблемалар шейрингі.
Аудиттің болмауы → бас тартуды түсіндіру мүмкін емес.

17) Жылдам рецепттер

Мөлшерлемені қабылдау: 'max _ bet' = min (өңір, ойын, провайдер, пайдаланушы RG); '/bets. place '= 20 rps/player, QUOTA = 500 ставка/күн.
Депозиттер: 'deposit _ daily/monthly' + 'deposit _ single'; PSP-лимиттерін алдын ала валидациялау.
Сессиялар: 'session _ duration' hard + ескертулер әрбір N минут сайын (soft).
API-қорғау: 'ip _ asn' және 'tenant _ id' кілттері бойынша жаһандық RATE; релиздерге арналған канареялық терезелер.

18) Азық-түлік алдындағы чек-парағы

• Мердждің ерекшелігі мен саясаты (most specific wins, deny> allow) белгіленді.
• 'scope', 'kind', 'type', терезелері, валюталары және басымдықтары бар деректер үлгісі.
• Қолдану нүктелері: gateway (RATE), домен (QUOTA/ақшалай), адаптерлер (провайдерлік).
• Идемпотенттілік ('operation _ id') және кілттер бойынша сериалдандыру; атомарлы есептеуіштер.
• Бақылануы: шешімдердің метрикасы, терезе лагтары, алерта; 'matched _ limit _ id'.
• Нұсқалау және өзгерістер мен іске қосылулардың өзгермейтін аудиті.
• Тест-пакет: contract/property/golden/chaos/E2E.
• fairness және data residency мульти-тенанты сақталған.
• UX SOFT-лимиттері үшін: түсінікті хабарлар, 'remaining/retry _ after'.
• Инциденттердің плейбуктері комплаенспен және қолдаумен келісілген.

Қорытынды

Лимиттер иерархиясы - бұл бытыраңқы сандар жинағы емес, шешім қабылдау жүйесі. Басымдықтардың нақты ерекшелігі мен тәртібі, деректердің бірыңғай моделі, дұрыс қолдану нүктелері, демпотенттілік пен байқау лимиттерді қауіпсіздік пен сәйкестіктің сенімді контурына айналдырады, ол тенанттар, өңірлер және өнімдер бойынша масштабталады және өсуге кедергі келтірмейді.