Hierarchia limitów

Limit jest sformalizowanym ograniczeniem operacji w czasie/objętości/wartości. W iGaming i fintech limity stanowią podstawę bezpieczeństwa, zgodności z przepisami i zarządzania ryzykiem. Hierarchia limitów określa, której reguły są najważniejsze i gdzie są wykonywane, aby zapobiec podwójnym wydatkom, przekraczającym zakłady/depozyty, nadużyciom bonusów i naruszeniom odpowiedzialnej gry.

1) Klasyfikacja limitów

Według siły aplikacji

Hard - nie do pokonania (zakaz eksploatacji).
Miękkie - ostrzeżenie/tarcie (captcha, potwierdzenie), eskalacja do twardego po powtórzeniu.

Z natury

Gotówka: kwota depozytu/stawki/płatności; dzienne/tygodniowe/miesięczne limity.
Czas: czas trwania sesji, przerwy, „chłodzenie”, timeouts.
Ilościowe: liczba transakcji, spinów, żądań API.
Limity stawki: RPS/konkurencja.
Kwoty: budżet działań na okno (N dziennie/tydzień).
Kontekst: według gry/dostawcy/metody płatności/urządzenia/kraju.

Przez właściciela

Regulacja/Marka (Najemca/Region)

System (platforma, ochrona infrastruktury)

Zdefiniowane przez użytkownika (samoograniczenia w ramach RG)

2) Pomiary i klucze (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

Im dokładniejszy klucz, tym wyższy priorytet (patrz hierarchia poniżej).

3) Hierarchia i priorytety (większość konkretnych wygranych)

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

• Węższy kontekst nakłada się na szeroki: gracz> region.
• Każde wyraźne zaprzeczenie pozwala wygrać.
• Konflikty miękkie/twarde są rozwiązywane na korzyść twardych.
• Wraz z połączeniem kwot/okien wygrywa minimalna dopuszczalna wartość (min-cap).

4) Model danych (uproszczony)

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

Idempotencja: wszystkie operacje posiadają 'operation _ id'; przyrost licznika jest wykonywany raz (skrzynka odbiorcza/skrzynka odbiorcza lub porównanie-i-swap zgodnie z wersją).

5) Algorytm oceny

1. Zbieranie kandydatów według „rodzaju” i przekraczanie „zakresu”.
2. Ranking według specyfiki (liczba dopasowanych pomiarów) i „priorytet”.
3. Zakres parametrów: twardość (twarda> miękka), min-cap, min-window.
4. Sprawdź kwoty/limit stawki: wiadro tokenowe (RATE) + okno stałe/przesuwne (QUOTA).
5. Ревений: 'PERMIT | SOFT_WARN | DENY' + 'retry _ after '/' remaining'.
6. Trace record: audyt i mierniki.

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) Punkty egzekucyjne

API Gateway - ochrona infrastruktury: RATE (RPS), CONCURRENCY, burst.
Usługi domenowe - limity semantyczne: depozyty, stawki, płatności, sesje.
Adaptery dostawcy - duplikat/lokalny limit dostawcy (potwierdzenie przed wywołaniem).
Klient UX - komunikaty zapobiegawcze (SOFT), „N left”, timery.

Reguła: raz odpis kontyngentu/żetonów - gdy operacja staje się nieodwracalna (po utworzeniu kopii zapasowej portfela/ważnego uwierzytelnionego kroku).

7) Limity pieniężne: depozyt/stopa/wypłata

W walucie: Przechowywać limity w walucie transakcji, a nie przez FX w locie.
Min/Max: 'min _ bet',' max _ bet', 'max _ payout _ single'.
System Windows: 'deposit _ daily/weekly/monthly' ze stałymi granicami (na przykład w harmonogramie licencji).
Skład: końcowy dozwolony zakres = przecięcie (regionalna marka, niestandardowa).

8) Odpowiedzialna gra (RG)

Samodzielne ograniczenia (gracz zadał sobie pytanie) są zawsze trudniejsze niż markowe.
Terminy: 'session _ duration', 'cool _ off', 'self _ exclusion'.
Eskalacja: przekraczająca miękki limit → ostrzeżenie, powtarzając twarde → (w oknie).
Audyt: Każda zmiana RG jest rejestrowana niebocznie (kto/kiedy/dlaczego).

9) Limit stawki vs Kontyngent: kiedy co

Limit szybkości (wiadro żetonowe/wyciek): ochrona przed przepięciami; stosować na bramie/adapterach.
Kwota (okno stałe/przesuwne): zarządzanie całkowitym budżetem działań/pieniędzy; zastosowanie w domenie (deposit_daily, bet_count_hourly).
Często używane razem: 'RATE' (piki błyskawiczne) + 'QUOTA' (budżet dzienny).

10) Wielopoziomowy i wielobranżowy

Limity zawsze zawierają 'lokator _ id' i' region/licencja '.
Miejsce zamieszkania: liczniki i magazynowanie - w regionie „domowym”.

Uczciwość: Oddzielna stawka/kwota na baseny najemców, więc „hałaśliwy” nie zakłóca innych SLO

11) Idempotencja i spójność

Polecenia z 'operation _ id'; powtarzanie nie powinno zwiększać „zużytego”.
Dla pieniędzy - ścisła ścieżka: rezerwy portfela i liczniki przyrostów w jednej transakcji/sadze (TCC).
Dla RATE - użyj przyrostów atomowych/magazynów bieżące okno.

12) Obserwowalność

• „limit _ eval _ p95 _ ms”, „decision _ rate {PERMIT, DENY, SOFT}”,
• "quota _ remaining _ percent 'według głównych gatunków,
• „rate _ throttled”, „burst _ dropped”,
• 'rg _ self _ limit _ hits', 'regulatory _ hits'.

Лова/трексин, 'matched _ limit _ id',' scope _ hash ',' operation _ id', 'window _ start/reset', 'remaining'.

Wpisy: wzrost 'DENY '/' 429' powyżej progu, częste osiąganie czapek regulacyjnych, 'hot key' przez gracza/urządzenia.

13) Weryfikacja i audyt

Każda reguła jest z 'valid _ from/valid _ to', 'created _ by', 'reason _ code'.
Сова тий: 'LimitCreated/Updated/Deleted', 'LimitHit', 'LimitDeNied'.
Zachowaj „migawkę” aktywnych zasad, aby odtworzyć historyczne decyzje (spór-gotowy).

14) Badanie

Testy kontraktowe: schemat i zakres specyfiki/priorytetów.
Nieruchomości: „większość konkretnych wygranych”, „zaprzeczenie wygranych pozwala”, „min-cap”.
Złote przypadki: zbiór konfliktów referencyjnych (lokator vs region, RG vs marka).
Chaos: Kolce żądania (RATE), wyścigi liczenia, komendy powtarzania (idempotencja).
E2E: mecze limitu na listach kontrolnych regulatora (depozyt/tydzień/miesiąc).

15) Playbooks

1. Burza 429/przepustnica na bramie

Zmniejszyć jednoczesność, tymczasowo zwiększyć token-wiadro, umożliwić priorytetyzację ścieżek krytycznych, analizować źródła (ASN/IP).

2. Niedociągnięcia masowe według limitu regulacyjnego

Sprawdź harmonogram okien i timezon; przedłużyć miękkie UX (wyjaśnienia), powiadomić o zgodności.

3. Fałszywie pozytywne awarie z powodu wyścigów

Włączanie serializacji przez klucz 'player _ id/kind', przełączanie na CAS/dedup przez 'operation _ id'.

4. Rozbieżność z limitem dostawcy

Zsynchronizować min/max na grę, dodać wstępną walidację do adaptera, tymczasowo obniżyć katalog/umieszczenie gry.

16) Typowe błędy

Brak hierarchii → holownik wojny między zasadami.
Obliczanie limitów w interfejsie użytkownika bez weryfikacji serwera.
Zastąpienie kwot limitami stawek (i odwrotnie).
Ignorowanie walut/kroków z limitami pieniężnymi (CLP/JPY).
Brak idempotencji → podwójne umorzenie kwot.
Pojedyncza pula STAWKI dla wszystkich najemców → problemy z strzyżeniem.
Żadnego audytu → nie można wyjaśnić.

17) Szybkie przepisy kulinarne

Akceptacja oferty: 'max _ bet' = min (region, gra, dostawca, użytkownik RG); STAWKA na '/zakłady. place '= 20 rps/player, QUOTA = 500 zakładów/dzień.
Depozyty: „deposit _ daily/monthly” + „deposit _ single”; wstępnie zwalidować limity PSP.
Sesje: 'session _ duration' hard + przypomina co N minut (miękki).
Ochrona API: GLOBAL RATE przy pomocy klawiszy „ip _ asn' i” najemca _ id'; kanarkowe okna do wydawania.

18) Lista kontrolna przedsprzedaży

• Większość konkretnych wygranych, zaprzeczam> zezwalaj.
• Model danych z „zakresem”, „rodzaju”, „typu”, okien, walut i priorytetów.
• Punkty zastosowania: brama (RATE), domena (QUOTA/money), adaptery (dostawca).
• Idempotencja ("operation _ id') i serializacja za pomocą klawiszy; Liczniki są atomowe.
• Obserwowalność: mierniki rozwiązań, opóźnienia okienne, wpisy; ślad z 'matched _ limit _ id'.
• Weryfikacja i niezmieniony audyt zmian i aktualizacji.
• Pakiet testowy: contract/property/golden/chaos/E2E.
• Spełniono wymogi dotyczące uczciwości i miejsca zamieszkania dla wielu najemców.
• UX dla limitów SOFT: przyjazne wiadomości, „remaining/retry _ after”.
• Playbooks incydentów są dostosowane do zgodności i wsparcia.

Wnioski

Hierarchia granic to system decyzji, a nie zbiór liczb rozbieżnych. Jasna specyfika i kolejność priorytetów, jednolity model danych, odpowiednie punkty zastosowania, idempotencja i obserwowalność przekształcają ograniczenia w solidną pętlę bezpieczeństwa i zgodności, która jest skalowana między najemcami, regionami i produktami - i nie utrudnia wzrostu.