Ієрархія лімітів

Ліміт - це формалізоване обмеження операції в часі/обсязі/вартості. У iGaming і фінтехе ліміти - основа безпеки, відповідності регуляціям і управління ризиками. Ієрархія лімітів задає, чиє правило головніше і де воно виконується, щоб не допустити подвійної витрати, перевищення ставок/депозитів, зловживань бонусами і порушень відповідальної гри.

1) Класифікація лімітів

За силою застосування

Hard - непереборні (заборона операції).
Soft - попередження/фрикція (капча, підтвердження), ескалація до hard при повторі.

За природою

Грошові: сума депозиту/ставки/виплати; денні/тижневі/місячні межі.
Тимчасові: тривалість сесії, перерви, «охолодження», тайм-аути.
Кількісні: число транзакцій, спінів, запитів API.
Швидкісні (rate limits): RPS/конкурентність.
Квоти: бюджет дій за вікно (N на добу/тиждень).
Контекстні: по грі/провайдеру/методу оплати/пристрою/країні.

За власником

Регуляторні/брендові (тенант/регіон)

Системні (платформа, захист інфраструктури)

Призначені для користувача (self-limits в рамках RG)

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. Шторм 429/throttling на gateway

Знизити concurrency, збільшити токен-бакет тимчасово, включити пріоритизацію критичних шляхів, проаналізувати джерела (ASN/IP).

2. Масові відмови щодо регуляторного ліміту

Перевірити розклад вікон і таймзону; пролонгувати soft-UX (пояснення), повідомити комплаєнс.

3. Помилково-позитивні відмови через перегони

Включити серіалізацію по ключу'player _ id/kind', перейти на CAS/дедуп по'operation _ id'.

4. Розбіжність з провайдерським лімітом

Синхронізувати min/max per game, додати передвалідацію в адаптер, тимчасово знизити каталог/плейсмент гри.

16) Типові помилки

Відсутність ієрархії → «перетягування каната» між правилами.
Обчислення лімітів в UI без серверної валідації.
Підміна квот рейт-лімітами (і навпаки).
Ігнорування валют/кроків при грошових лімітах (CLP/JPY).
Немає ідемпотентності → подвійне списання квоти.
Єдиний пул RATE на всіх тенантів → шейрінг проблем.
Відсутність аудиту → неможливо пояснити відмову.

17) Швидкі рецепти

Прийом ставки: 'max _ bet'= min (регіон, гра, провайдер, користувацький RG); RATE на '/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') і серіалізація за ключами; лічильники атомарні.
• Спостережуваність: метрики рішень, лаги вікон, алерти; трасування з'matched _ limit _ id'.
• Версіонування і незмінний аудит змін і спрацьовувань.
• Тест-пакет: contract/property/golden/chaos/E2E.
• Мульти-тенант fairness і data residency дотримані.
• UX для SOFT-лімітів: зрозумілі повідомлення,'remaining/retry _ after'.
• Плейбуки інцидентів узгоджені з комплаєнсом і підтримкою.

Висновок

Ієрархія лімітів - це система прийняття рішень, а не набір розрізнених чисел. Чітка специфічність і порядок пріоритетів, єдина модель даних, правильні точки застосування, ідемпотентність і спостережуваність перетворюють ліміти в надійний контур безпеки і відповідності, який масштабується по тенантах, регіонах і продуктах - і не заважає зростанню.