Limitlar ierarxiyasi

Limit - operatsiyani vaqt/hajm/qiymat bo’yicha rasmiylashtirilgan cheklashdir. iGaming va fintexda limitlar xavfsizlik, tartibga solish va xatarlarni boshqarish asosi hisoblanadi. Limitlar ierarxiyasi ikki marta sarf qilish, stavkalar/depozitlarni oshirib yuborish, bonuslarni suiiste’mol qilish va mas’uliyatli o’yin buzilishiga yo’l qo’ymaslik uchun kimning qoidasi muhimroq va qayerda bajarilishini belgilaydi.

1) Limitlar tasnifi

Qo’llash kuchiga ko’ra

Hard - yengib bo’lmaydigan (operatsiyalarni taqiqlash).
Soft - ogohlantirish/friksiya (kapcha, tasdiqlash), takrorlashda hard gacha eskalatsiya.

Tabiatga ko’ra

Pul: depozit summasi/stavkalar/to’lovlar; kunduzgi/haftalik/oylik chegaralar.
Vaqtinchalik: sessiya davomiyligi, tanaffuslar, «sovutish», taym-autlar.
Miqdor: tranzaksiyalar, spinlar, API soʻrovlari soni.
Tezlik (rate limits): RPS/raqobatbardoshlik.
Kvotalar: deraza uchun harakatlar budjeti (N sutka/hafta).
Kontekst: o’yin/provayder/to’lov usuli/qurilma/mamlakat.

Egasiga ko’ra

Tartibga soluvchi/brend (tenant/mintaqa)

Tizimli (platforma, infratuzilmani himoya qilish)

Foydalanuvchilar (RG doirasidagi self-limits)

2) O’lchovlar va kalitlar (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

Kalit qanchalik aniqroq boʻlsa, ustuvorlik shunchalik yuqori boʻladi (quyidagi ierarxiyaga qarang).

3) Ierarxiya va ustuvorliklar (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)

• Kengroq kontekst: player> region.
• Har qanday aniq deny allow g’alaba qozonadi.
• soft/hard mojarolari hard foydasiga hal qilinadi.
• Kvotalar/derazalar merjasida eng kam yo’l qo’yiladigan qiymat (min-cap) g’alaba qozonadi.

4) Ma’lumotlar modeli (soddalashtirilgan)

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

Idempotentlik: barcha operatsiyalar’operation _ id’; hisoblagichning inkrementi bir marta bajariladi (inbox/outbox yoki compare-and-swap versiyasi bo’yicha).

5) Baholash algoritmi (evaluation)

1. ’kind’ va’scope’kesishmasi bo’yicha nomzodlarni yig’ish.
2. O’ziga xosligi bo’yicha (bir xil o’lchovlar soni) va’priority’.
3. Merj parametrlari: qattiqlik (hard> soft), min-cap, min-window.
4. Kvota/reyt-limitni tekshirish: token-baket (RATE) + fiks/sirpanuvchi oyna (QUOTA).
5. Решение: `ALLOW | SOFT_WARN | DENY` + `retry_after`/`remaining`.
6. Izni yozish: hodisa va metrika auditi.

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) Qo’llash nuqtalari (enforcement points)

API Gateway - infratuzilmani himoya qilish: RATE (RPS), CONCURRENCY, burst.
Domen xizmatlari - semantik limitlar: depozitlar, stavkalar, to’lovlar, sessiyalar.
Provayder adapterlari - provayderlarning takrorlanuvchi/lokal limitlari (chaqiruvgacha validatsiya qilish).
Mijoz UX - preventiv maslahatlar (SOFT), «N qoldi», taymerlar.

Qoida: bir marta kvota/tokenlarni - operatsiya qaytarib bo’lmaydigan bo’lib qolganda (hamyonni/haqiqiy autentifikatsiyalangan qadamni zaxiralashdan keyin) hisobdan chiqaramiz.

7) Pul limitlari: depozit/stavka/to’lov

Per currency: limitlarni FX orqali emas, balki operatsiya valyutasida saqlang.
Min/Max: `min_bet`, `max_bet`, `max_payout_single`.
Oynalar: chegaralari belgilangan’deposit _ daily/weekly/monthly’(masalan, litsenziya taymzonida).
Kompozitsiya: ruxsat etilgan yakuniy diapazon = kesishma (mintaqaviy ∩ brend ∩ foydalanuvchi).

8) Mas’uliyatli o’yin (RG)

Self-limits (o’yinchining o’zi) har doim brendlarga qaraganda qattiqroq.
Vaqtni cheklash:’session _ duration’,’cool _ off’,’self _ exclusion’.
Eskalatsiya: soft-limitdan oshib ketish → ogohlantirish, takrorlash → hard (oyna doirasida).
Audit: RGning har bir o’zgarishi tuzatib bo’lmaydigan tarzda qayd etiladi (kim/qachon/nima uchun).

9) Rate limit vs Quota: qachon nima

Rate limit (token-bucket/leaky): portlashlardan himoya qilish; gateway/adapterlarda qoʻllash.
Quota (fixed/sliding window): harakatlar/pullarning jami budjetini boshqarish; domenda qo’llash (deposit_daily, bet_count_hourly).
Ko’pincha birgalikda ishlatiladi:’RATE’(tezkor cho’qqilar) +’QUOTA’(kunlik byudjet).

10) Ko’p tenant va ko’p mintaqa

Chegaralarda doimo’tenant _ id’va’region/licence’mavjud.
Residency: hisoblagichlar va saqlash - «uy» hududida.
Fairness: RATE/QUOTA per tenant pullarini ajrating, shunda «shovqin» boshqalarning SLOlarini buzmaydi.

11) Idempotentlik va konsistentlik

Buyruqlar’operation _ id’; takrorlash’consumed’ni oshirmasligi kerak.
Pul uchun - strict path: rezerv hamyon va inkrement counters bitta tranzaksiya/sage (TCC).
RATE uchun - joriy oynaning atom inkrementlari/omborlaridan foydalaning.

12) Kuzatish

• `limit_eval_p95_ms`, `decision_rate{ALLOW,DENY,SOFT}`,
• ’quota _ remaining _ percent’ asosiy turlari bo’yicha,
• `rate_throttled`, `burst_dropped`,
• `rg_self_limit_hits`, `regulatory_hits`.

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

Alertlar:’DENY ’/’ 429’ning ostonadan yuqori bo’lishi, regulyator kaplarining tez-tez erishilishi, o’yinchi/qurilma bo’yicha «hot key».

13) Versiyalash va audit

Har bir qoida -’valid _ from/valid _ to’,’created _ by’,’reason _ code’.
События: `LimitCreated/Updated/Deleted`, `LimitHit`, `LimitDenied`.
Tarixiy yechimlarni (dispute-ready) takrorlash uchun aktiv qoidalarning «rasmini» saqlang.

14) Test sinovlari

Contract tests: xususiyatlar/ustuvorliklar sxemasi va merj.
Property-based: «most specific wins», «deny allow», «min-cap».
Golden cases: etalon mojarolari to’plami (tenant vs region, RG vs brend).
Chaos: so’rovlar portlashi (RATE), hisoblagichlar bo’yicha poygalar, buyruqlarni takrorlash (idempotentlik).
E2E: regulyatorning chek varaqalaridagi limitlar matchingi (depozit/hafta/oy).

15) Pleybuklar

1. Gateway bo’roni 429/throttling

Concurrency ni kamaytirish, token-baketni vaqtincha ko’paytirish, tanqidiy yo’llarni ustuvorlashtirish, manbalarni tahlil qilish (ASN/IP).

2. Tartibga solish limiti bo’yicha ommaviy rad etish

Oynalar va taymzonlar jadvalini tekshirish; soft-UX (tushuntirishlar) ni uzaytirish, komplayensni xabardor qilish.

3. Poygalar tufayli noto’g "ri-ijobiy rad etishlar

Serializatsiyani’player _ id/kind’bilan yoqish,’operation _ id’uchun CAS/dedupga oʻtish.

4. Provayder limiti bilan tafovut

min/max per game ni sinxronlashtirish, adapterga oldindan validatsiyani qoʻshish, oʻyin katalogini/pleysmentini vaqtincha pasaytirish.

16) Tipik xatolar

Yo’qligi → qoidalar o’rtasida «arqon tortish».
Server validatsiyasisiz limitlarni hisoblash.
Kvotalarni reyt-limitlar bilan almashtirish (va aksincha).
Pul limitlarida (CLP/JPY) valyuta/qadamlarni e’tiborsiz qoldirish.
Idempotentlik yoʻq → kvotani ikki marta hisobdan chiqarish.
Barcha tenantlar uchun yagona RATE puli → sheyring muammolari.
Auditning yoʻqligi → rad etishni tushuntirib boʻlmaydi.

17) Tezkor retseptlar

Stavkani qabul qilish:’max _ bet’= min (mintaqa, o’yin, provayder, foydalanuvchi RG); RATE na ’/bets. place’= 20 rps/player, QUOTA = 500 stavka/kun.
Depozitlar:’deposit _ daily/monthly’+’deposit _ single’; PSP-limitlarni oldindan validlash.
Seanslar:’session _ duration’hard + har N daqiqada eslatmalar (soft).
API-himoya:’ip _ asn’va’tenant _ id’kalitlari boʻyicha global RATE; relizlar uchun kanar oynalari.

18) Sotishdan oldingi chek-varaq

• O’ziga xoslik ierarxiyasi va merj siyosati (most specific wins, deny> allow) qayd etilgan.
• Maʼlumotlar modeli’scope’,’kind’,’type’, oynalar, valyutalar va ustuvorliklar bilan.
• Qo’llanish nuqtalari: gateway (RATE), domen (QUOTA/pul), adapterlar (provayder).
• Idempotentlik (’operation _ id’) va kalitlar bo’yicha seriallashtirish; atomar hisoblagichlar.
• Kuzatish darajasi: yechimlar metrikasi, deraza laglari, alertlar; ’matched _ limit _ id’.
• O’zgarishlar va ishlanmalarni versiyalash va o’zgarmas audit.
• Test paketi: contract/property/golden/chaos/E2E.
• Multi-tenant fairness va data residency kuzatildi.
• UX SOFT limitlari uchun: tushunarli xabarlar,’remaining/retry _ after’.
• Hodisalarning pleybuklari komplayens va qo’llab-quvvatlash bilan kelishilgan.

Xulosa

Limit ierarxiyasi - bu turli raqamlar to’plami emas, balki qarorlar qabul qilish tizimidir. Ustuvorliklarning aniq o’ziga xosligi va tartibi, ma’lumotlarning yagona modeli, to’g "ri qo’llanish nuqtalari, idempotentlik va kuzatuvchanlik limitlarni xavfsizlik va muvofiqlikning ishonchli konturiga aylantiradi, bu esa tenantlar, hududlar va mahsulotlar bo’yicha o’sishga to’sqinlik qilmaydi.