ლიმიტის იერარქია

ლიმიტი არის ოპერაციის ოფიციალური შეზღუდვა დროში/მოცულობაში/ღირებულებაში. IGaming- სა და ფინანსურ ტექნიკაში, ლიმიტები არის უსაფრთხოების საფუძველი, რეგულაციებთან შესაბამისობა და რისკების მართვა. ლიმიტების იერარქია ადგენს, ვისი წესი უფრო მნიშვნელოვანია და სად ხორციელდება, რათა თავიდან აიცილოს ორმაგი ხარჯვა, განაკვეთების/დეპოზიტების გადაჭარბება, ბონუსების ბოროტად გამოყენება და საპასუხისმგებლო თამაშის დარღვევა.

1) ლიმიტების კლასიფიკაცია

გამოყენების ძალით

Hard არის გადაულახავი (ოპერაციის აკრძალვა).
რბილი - გაფრთხილება/ხახუნი (ქუდი, დადასტურება), გამეორების დროს ესკალაცია.

ბუნებით

ფულადი სახსრები: ანაბარი/განაკვეთები/გადახდები; დღისით/ყოველკვირეული/ყოველთვიური შეზღუდვები.
დროებითი: სესიის ხანგრძლივობა, შესვენებები, „გაცივება“, დრო.
რაოდენობრივი: გარიგების, სპინების, API- ს მოთხოვნების რაოდენობა.
მაღალსიჩქარიანი ლიმიტები: RPS/კონკურენტუნარიანობა.
კვოტები: ფანჯრის მოქმედების ბიუჯეტი (N დღეში/კვირაში).
კონტექსტური: თამაშში/პროვაიდერი/გადახდის მეთოდი/მოწყობილობა/ქვეყანა.

მფლობელის მიხედვით

მარეგულირებელი/ბრენდირებული (ტენანტი/რეგიონი)

სისტემური (პლატფორმა, ინფრასტრუქტურის დაცვა)

მომხმარებლის (self-limits RG- ის ფარგლებში)

2) გაზომვები და გასაღებები

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) იერარქია და პრიორიტეტები

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

• ვიწრო კონტექსტი მოიცავს ფართო: player> region.
• ნებისმიერი აშკარა დენი იმარჯვებს ალოუ.
• რბილი/მძიმე კონფლიქტები წყდება ჰარდის სასარგებლოდ.
• კვოტების/ფანჯრების ზომით იმარჯვებს მინიმალური დასაშვები მნიშვნელობა (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
);

Idempotence: ყველა ოპერაცია ახორციელებს 'operation _ id'; მრიცხველის შემცირება ხორციელდება ერთხელ (inbox/outbox ან compare-and-swap ვერსიის მიხედვით).

5) შეფასების ალგორითმი

1. 'kind' კანდიდატების შეგროვება და 'scope' კვეთა.
2. სპეციფიკის რანგი (თანაბარი გაზომვების რაოდენობა) და 'პრიორიტეტი ".
3. Merge პარამეტრი: სიმტკიცე (მძიმე> რბილი), min-cap, min-window.
4. კვოტების/RHIT ლიმიტის შემოწმება: docken-backet (RATE) + fix/მოცურების ფანჯარა (QUTA).
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) გამოყენების წერტილები

API Gateway - ინფრასტრუქტურის დაცვა: RATE (RPS), CONCURRENCY, burst.
დომენის სერვისები - სემანტიკური ლიმიტები: ანაბრები, განაკვეთები, გადახდები, სესიები.
Provaider გადამყვანები - პროვაიდერების დუბლიკატი/ადგილობრივი ლიმიტები (ზედამხედველობა ზარის დაწყებამდე).
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'.
ესკალაცია: რბილი ლიმიტის ჭარბი რაოდენობა - გაფრთხილება, გამეორება (როგორც ფანჯრის ნაწილი).
აუდიტი: RG- ს თითოეული ცვლილება აღირიცხება არათანაბრად (ვინ/როდის/რატომ).

9) როდის

Rate limit (token-bucket/leaky): დაცვა ადიდებისგან; გამოიყენეთ gateway/ადაპტერებზე.
~ ta (fixed/sliding window): სამოქმედო/ფულის მთლიანი ბიუჯეტის მენეჯმენტი; გამოიყენეთ დომენში (deposit _ daily, bet _ count _ hourly).
ხშირად ერთად გამოიყენება: 'RATE' (მყისიერი მწვერვალები) + 'ÉTA' (ყოველდღიური ბიუჯეტი).

10) მულტფილმები და მულტფილმის რეგიონი

ლიმიტები ყოველთვის შეიცავს 'tenant _ id' და 'region/licence'.
Residence: მრიცხველები და შენახვა - „საშინაო“ რეგიონში.
Fairness: გაიზიარეთ RATE/QUTA per tenant აუზები ისე, რომ „ხმაურიანი“ არ შეუშალოს სხვებს SLO.

11) Idempotence და Consistence

'operation _ id' ბრძანებები; გამეორებამ არ უნდა გაზარდოს 'consumed'.
ფულისთვის - მკაცრი პატჩი: საფულის რეზერვი და კოუნტერების კვალი ერთ გარიგებაში/საგაში (TCC).
RATE- სთვის - გამოიყენეთ მიმდინარე ფანჯრის ატომური ნიშნები/საწყობები.

12) დაკვირვება

• `limit_eval_p95_ms`, `decision_rate{ALLOW,DENY,SOFT}`,
• ძირითადი სახეობებისთვის 'quta _ 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' ზღურბლზე მეტი, მარეგულირებელი ქუდის ხშირი მიღწევა, მოთამაშის/მოწყობილობის მიხედვით „ცხელი ქუდი“.

13) ვერსია და აუდიტი

თითოეული წესი არის 'valid _ from/valid _ to', 'created _ by', 'reason _ code'.
События: `LimitCreated/Updated/Deleted`, `LimitHit`, `LimitDenied`.
შეინახეთ აქტიური წესების „სურათი“ ისტორიული გადაწყვეტილებების რეპროდუქციისთვის.

14) ტესტირება

Contract tests: სპეციფიკური/პრიორიტეტების სქემა და ზღვარი.
Property-based: „most specific wins“, „deny იმარჯვებს allow“, „min-cap“.
Golden cases: საცნობარო კონფლიქტების ერთობლიობა (ტენანტი vs რეგიონი, RG vs ბრენდი).
ქაოსი: მოთხოვნის ზრდა (RATE), მრიცხველების რბოლა, გუნდების გამეორება (იდემპოტენტობა).
E2E: რეგულატორის შემოწმების სიებზე ლიმიტების მატჩები (ანაბარი/კვირა/თვე).

15) პლეიბუკი

1. ქარიშხალი 429/throttling gateway

შეამცირეთ concurrency, დროებით გაზარდეთ ნიშანი, შეიტანეთ კრიტიკული ბილიკების პრიორიტეტი, გაანალიზეთ წყაროები (ASN/IP).

2. მასობრივი უარი მარეგულირებელი ლიმიტის შესახებ

შეამოწმეთ ფანჯრის გრაფიკი და ტაიმზონი; შეამოწმეთ სოლო-UX (ახსნა), შეატყობინეთ შესაბამისობას.

3. ყალბი და პოზიტიური უარი რბოლაზე

ჩართეთ სერია 'player _ id/kind' გასაღებით, გადადით CAS/dedup- ზე 'operation _ id' - ში.

4. შეუსაბამობა პროვაიდერის ლიმიტით

სინქრონიზაცია min/max per game, დაამატეთ წინასწარ შეფერხება ადაპტერში, დროებით შეამცირეთ თამაშის დირექტორია/თამაში.

16) ტიპიური შეცდომები

იერარქიის არარსებობა არის „თოკის გადატანა“ წესებს შორის.
ლიმიტების გაანგარიშება UI- ში სერვერის ვალიდაციის გარეშე.
კვოტების შეცვლა Rhit-limites (და პირიქით).
ვალუტის/ნაბიჯების უგულებელყოფა ფულადი ლიმიტების დროს (CLP/JPY).
არ არსებობს იდემპოტენტობა - კვოტის ორმაგი ჩამოწერა.
ყველა ტენანტისთვის ერთი RATE აუზი არის პრობლემების შეერინგი.
აუდიტის არარსებობა უარის თქმის ახსნა შეუძლებელია.

17) სწრაფი რეცეპტები

განაკვეთის მიღება: 'max _ bet' = min (რეგიონი, თამაში, პროვაიდერი, მომხმარებლის RG); RATE '/bets. place '= 20 rps/player, ICTA = 500 ფსონი/დღე.
დეპოზიტები: 'deposit _ daily/monthly' + 'deposit _ single "; წინამორბედი PSP ლიმიტები.
სესიები: 'session _ duration' hard + შეხსენებები ყოველ N წუთში (რბილი).
API დაცვა: გლობალური RATE გასაღებებზე 'ip _ asn' და 'tenant _ id'; კანარის ფანჯრები გამოშვებისთვის.

18) ჩეკის სია გაყიდვამდე

• დაფიქსირდა სპეციფიკურობის იერარქია და მერჯის პოლიტიკა (most specific wins, deny> allow).
• მონაცემთა მოდელი 'scope', 'kind', 'ტიპი', ფანჯრები, ვალუტები და პრიორიტეტები.
• გამოყენების წერტილები: gateway (RATE), დომენი (ICTA/ფულადი), გადამყვანები (პროვაიდერები).
• idempotention ('operation _ id') და სერიალიზაცია კლავიშებზე; მრიცხველები ატომურია.
• დაკვირვება: გადაწყვეტილებების მეტრიკა, ფანჯრების ბლოკები, ალერტები; კვალი 'matched _ limit _ id'.
• ვერსია და ცვლილებებისა და ოპერაციების უცვლელი აუდიტი.
• ტესტის პაკეტი: contract/property/golden/chaos/E2E.
• შეინიშნება fairness და მონაცემთა გამოკითხვა.
• UX SOFT ლიმიტებისთვის: გასაგები შეტყობინებები, 'remaining/retry _ after'.
• ინციდენტების ფლეიბუკი შეთანხმებულია შესაბამისობასთან და მხარდაჭერასთან.

დასკვნა

ლიმიტების იერარქია არის გადაწყვეტილების მიღების სისტემა და არა განსხვავებული რიცხვების ერთობლიობა. მკაფიო სპეციფიკა და პრიორიტეტული პროცედურა, მონაცემთა ერთიანი მოდელი, სწორი გამოყენების წერტილები, imempotence და დაკვირვება ლიმიტებს უსაფრთხოებისა და შესაბამისობის საიმედო მიკროსქემად აქცევს, რაც ფართომასშტაბიანია ტენანტების, რეგიონებისა და პროდუქტების მიხედვით - და ხელს არ უშლის ზრდას.