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

Лимит - операцияны убакытта/көлөмдө/наркта формалдуу чектөө. iGaming жана финтехте лимиттер коопсуздуктун, жөнгө салууларга шайкештиктин жана тобокелдиктерди башкаруунун негизи болуп саналат. Лимиттердин иерархиясы кимдин эрежеси эң негизгиси жана ал кайсы жерде аткарылып жатканын аныктайт, бул эки эселенген чыгымды, чендердин/депозиттердин ашып кетишин, бонустарды кыянаттык менен пайдаланууну жана жоопкерчиликтүү оюндун бузулушун болтурбоо үчүн.

1) Лимиттерди классификациялоо

Колдонуу күчү боюнча

Hard - жеңилбес (операцияга тыюу салуу).
Soft - эскертүү/фрикция (капча, ырастоо), кайталоодо катуу эскалация.

Табияты боюнча

Акча: депозиттин суммасы/коюмдар/төлөмдөр; күндүзгү/жумалык/айлык чектер.
Убактылуу: сессиянын узактыгы, тыныгуулар, "муздатуу", тайм-ауттар.
Сандык: транзакциялардын, спиндердин, API суроо-талаптардын саны.
Speed (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 чыр-чатактар ​ ​ катуу пайдасына чечилет.
• Мерджде квота/терезелер минималдуу жол берилген маанини (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.
Домен кызматтары - семантикалык лимиттер: депозиттер, ставкалар, төлөмдөр, сессиялар.
Провайдердик адаптерлер - провайдерлердин кайталануучу/локалдык лимиттери (чакырууга чейин валидациялоо).
Customer 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-чеги → эскертүү, кайталоо → катуу (терезе ичинде) ашып.
Аудит: ар бир өзгөрүү 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`.

Alerty: өсүү '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: эталондук чыр-чатактар ​ ​ топтому (tenant vs аймак, RG vs бренд).
Chaos: суроо-жарыш (RATE), эсептегичтер боюнча жарыш, команда кайталоо (боштондук).
E2E: жөнгө салуучунун чек баракчаларында лимит матчтары (депозит/жума/ай).

15) Playbook

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 бассейни → sheiring көйгөйлөр.
Аудит жоктугу → баш тартууну түшүндүрүү мүмкүн эмес.

17) Тез Recipes

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

18) Азык-түлүктүн алдындагы чек-тизме

• Белгиленген өзгөчө иерархиясы жана Мердж саясаты (most specific wins, deny> allow).
• Маалымат модели 'scope', 'kind', 'type', терезелер, валюталар жана артыкчылыктар менен.
• Колдонуу пункттары: gateway (RATE), домен (QUOTA/акча), адаптерлер (провайдер).
• Идемпотенттүүлүк ('operation _ id') жана ачкычтар боюнча сериалдаштыруу; атомдук эсептегичтер.
• Байкоо: чечимдердин метрикасы, терезе лагдары, алерт; менен tracking 'matched _ limit _ id'.
• Өзгөрүүлөрдү жана иштеп чыгууларды версиялоо жана өзгөрүлбөгөн аудит.
• Сыноо пакети: contract/property/golden/chaos/E2E.
• Multitenant fairness жана data residency сакталат.
• UX үчүн SOFT-чеги: түшүнүктүү билдирүүлөр, 'remaining/retry _ after'.
• Playbook окуялар комплаенс жана колдоо менен макулдашылган.

Корутунду

Лимиттердин иерархиясы - чечимдерди кабыл алуу системасы, чачыранды сандардын жыйындысы эмес. Артыкчылыктардын так өзгөчөлүгү жана тартиби, маалыматтардын бирдиктүү модели, колдонуунун туура пункттары, демпотенттүүлүк жана байкоо лимиттерди коопсуздуктун жана шайкештиктин ишенимдүү контуруна айландырат, ал тенанттар, аймактар жана продуктылар боюнча масштабдалат - жана өсүүгө тоскоол болбойт.