Limitlər iyerarxiyası

Limit əməliyyatın vaxt/həcm/dəyər üzrə rəsmiləşdirilmiş məhdudiyyətidir. iGaming və fintech limitləri təhlükəsizliyin, tənzimləmələrin və risklərin idarə edilməsinin əsasını təşkil edir. Limitlər iyerarxiyası kimin qaydasının daha vacib olduğunu və ikiqat xərclərin, həddən artıq dərəcələrin/depozitlərin, bonusların sui-istifadəsinin və məsuliyyətli oyunun pozulmasının qarşısını almaq üçün yerinə yetirildiyini müəyyən edir.

1) Limitlərin təsnifatı

Tətbiq gücünə görə

Hard - qarşısıalınmaz (əməliyyat qadağası).
Soft - xəbərdarlıq/sürtünmə (kapça, təsdiq), təkrar zamanı hard qədər eskalasiya.

Təbiətə görə

Pul: depozit məbləği/dərəcələr/ödənişlər; gündəlik/həftəlik/aylıq limitlər.
Müvəqqəti: sessiyaların müddəti, fasilələr, «soyutma», zaman-aut.
Kəmiyyət: əməliyyatların, spinlərin, API sorğularının sayı.
Sürətli (rate limits): RPS/rəqabət.
Kvotalar: pəncərə üçün fəaliyyət büdcəsi (gündə/həftədə N).
Kontekst: oyun/provayder/ödəniş metodu/cihaz/ölkə.

Sahibinə görə

Tənzimləyici/Marka (Tenant/Region)

Sistem (platforma, infrastrukturun qorunması)

Xüsusi (RG çərçivəsində self-limits)

2) Ölçmə və açarlar (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

Açar nə qədər dəqiqdirsə, prioritet o qədər yüksəkdir (aşağıda iyerarxiyaya baxın).

3) Hiyerarxiya və prioritetlər (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)

• Daha dar kontekst genişliyi əhatə edir: player> region.
• Hər hansı bir açıq deny allow qazanır.
• soft/hard münaqişələri hard lehinə həll olunur.
• Bu zaman kvota/pəncərə minimum icazə verilən dəyəri (min-cap) qazanır.

4) Məlumat modeli (sadələşdirilmiş)

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

İdempotentlik: bütün əməliyyatlar 'operation _ id' daşıyır; sayğac inkrement bir dəfə yerinə yetirilir (inbox/outbox və ya compare-and-swap versiyası).

5) Qiymətləndirmə alqoritmi (evaluation)

1. 'kind' və 'scope' keçidi üzrə namizədlərin toplanması.
2. Spesifikliyə görə sıralama (üst-üstə düşən ölçmələrin sayı) və 'priority'.
3. Merj parametrləri: sərtlik (hard> soft), min-cap, min-window.
4. Kvota/reyt limitinin yoxlanılması: token-baket (RATE) + fix/sürüşmə pəncərəsi (QUOTA).
5. Решение: `ALLOW | SOFT_WARN | DENY` + `retry_after`/`remaining`.
6. Track Record: hadisə və metrik audit.

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) Tətbiq nöqtələri (enforcement points)

API Gateway - infrastrukturun qorunması: RATE (RPS), CONCURRENCY, burst.
Domen xidmətləri - semantik limitlər: depozitlər, dərəcələr, ödənişlər, sessiyalar.
Provayder adapterləri - provayderlərin təkrarlanan/lokal limitləri (çağırışdan əvvəl validasiya).
Müştəri UX - profilaktik ipuçları (SOFT), «N qaldı», zamanlayıcılar.

Qayda: Əməliyyatın geri dönməz olduğu yerdə bir dəfə kvota/tokenləri silirik (cüzdan/etibarlı identifikasiya edilmiş addım sifariş edildikdən sonra).

7) Pul limitləri: depozit/dərəcə/ödəniş

Per currency: limitləri FX vasitəsilə deyil, əməliyyatın valyutasında saxlayın.
Min/Max: `min_bet`, `max_bet`, `max_payout_single`.
Pəncərələr: sabit sərhədləri olan 'deposit _ daily/weekly/monthly' (məsələn, lisenziya taymzonunda).
Kompozisiya: son icazə verilən diapazon = kəsişmə (regional ∩ marka ∩ xüsusi).

8) Məsuliyyətli oyun (RG)

Self-limits (oyunçu özü təyin) həmişə marka daha sərt.
Vaxt məhdudiyyətləri: 'session _ duration', 'cool _ off', 'self _ exclusion'.
Eskalasiya: yumşaq limiti aşmaq → xəbərdarlıq, təkrar → hard (pəncərə daxilində).
Audit: Hər bir RG dəyişikliyi aradan qaldırıla bilməz (kim/nə vaxt/niyə).

9) Rate limit vs Quota: nə zaman

Rate limit (token-bucket/leaky): sıçrayışlardan qorunma; gateway/adapterlərdə tətbiq olunur.
Quota (fixed/sliding window): ümumi fəaliyyət/pul büdcəsinin idarə edilməsi; domen tətbiq (deposit_daily, bet_count_hourly).
Tez-tez birlikdə istifadə olunur: 'RATE' (ani zirvələr) + 'QUOTA' (gündəlik büdcə).

10) Multi-tenant və multi-region

Limitlərdə həmişə 'tenant _ id' və 'region/licence' var.
Residency: sayğaclar və saxlama - «ev» bölgəsində.
Fairness: RATE/QUOTA per tenant hovuzlarını bölün ki, «səs-küylü» başqalarının SLO-larını pozmasın.

11) İdempotentlik və sabitlik

'operation _ id' ilə komandalar; təkrar 'consumed' artırmamalıdır.
Pul üçün - strict path: bir əməliyyat/dastanda cüzdan ehtiyatı və counters inkrement (TCC).
RATE üçün - atomik artımlardan/anbarlardan istifadə edin.

12) Müşahidə

• `limit_eval_p95_ms`, `decision_rate{ALLOW,DENY,SOFT}`,
• 'quota _ remaining _ percent' əsas növləri,
• `rate_throttled`, `burst_dropped`,
• `rg_self_limit_hits`, `regulatory_hits`.

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

Alertlər: 'DENY '/' 429' böyümə həddindən artıq, tez-tez tənzimləyici kaplara nail olmaq, oyunçu/cihaz üzrə «hot key».

13) Version və audit

Hər bir qayda - c 'valid _ from/valid _ to', 'created _ by', 'reason _ code'.
События: `LimitCreated/Updated/Deleted`, `LimitHit`, `LimitDenied`.
Tarixi həlləri (dispute-ready) ifa etmək üçün aktiv qaydaların «şəklini» saxlayın.

14) Test

Contract tests: sxem və merj spesifiklikləri/prioritetlər.
Property-based: «most specific wins», «deny allow», «min-cap».
Golden cases: istinad münaqişələri dəsti (tenant vs region, RG vs marka).
Chaos: sorğu sıçrayışları (RATE), sayğaclarda yarış, komandaların təkrarlanması (idempotentlik).
E2E: tənzimləyicinin yoxlama vərəqlərində limit matçları (depozit/həftə/ay).

15) Playbook

1. gateway fırtına 429/throttling

Concurrency azaltmaq, token baket müvəqqəti artırmaq, kritik yolları prioritetləşdirmək, mənbələri təhlil (ASN/IP).

2. Tənzimləyici limit üzrə kütləvi imtinalar

Pəncərə cədvəlini və taymzonu yoxlayın; soft-UX (izahlar) uzadılması, komplayens bildirin.

3. Yarış səbəbiylə yanlış-müsbət uğursuzluqlar

'player _ id/kind' açarı ilə serializasiyanı aktivləşdirin, 'operation _ id' üçün CAS/dedupa keçin.

4. Provayder limiti ilə uyğunsuzluq

min/max per game sinxronizasiya, adapter prevalidation əlavə, müvəqqəti kataloq/oyun playsment aşağı.

16) Tipik səhvlər

Hiyerarxiyanın olmaması → qaydalar arasında «ipin çəkilməsi».
Server validasiyası olmadan UI limitlərinin hesablanması.
Kvotaların reyt limitləri ilə dəyişdirilməsi (və əksinə).
Pul limitlərində (CLP/JPY) valyuta/addımlara məhəl qoymamaq.
No idempotance → cüt kvota silinməsi.
Bütün tenantlar üçün vahid RATE hovuzu → problemlərin qiymətləndirilməsi.
Yoxluq → imtina izah etmək mümkün deyil.

17) Sürətli reseptlər

Bahis qəbulu: 'max _ bet' = min (region, oyun, provayder, xüsusi RG); RATE on '/bets. place '= 20 rps/player, QUOTA = 500 bahis/gün.
Depozitlər: 'deposit _ daily/monthly' + 'deposit _ single'; PSP limitlərini əvvəlcədən təsdiqləmək.
Seanslar: 'session _ duration' hard + hər N dəqiqə xatırlatmalar (soft).
API qorunması: 'ip _ asn' və 'tenant _ id' açarları ilə qlobal RATE; relizlər üçün kanarya pəncərələri.

18) Satış öncəsi yoxlama siyahısı

• Xüsusi iyerarxiya və merj siyasəti (most specific wins, deny> allow).
• 'scope', 'kind', 'type', pəncərələr, valyutalar və prioritetlər ilə məlumat modeli.
• Tətbiq nöqtələri: gateway (RATE), domen (QUOTA/pul), adapterlər (provayder).
• İdempotentlik ('operation _ id') və açar serializasiyası; atom sayğacları.
• Müşahidə: həllərin metrikası, pəncərə laqları, həyəcan; 'matched _ limit _ id' ilə izləmə.
• Versiyalaşdırma və dəyişməz audit dəyişikliklər və istisnalar.
• Test paketi: contract/property/golden/chaos/E2E.
• Multi-tenant fairness və data residency riayət olunur.
• UX SOFT limitləri üçün: başa düşülən mesajlar, 'remaining/retry _ after'.
• Hadisə pleybukları komplayens və dəstək ilə razılaşdırılmışdır.

Nəticə

Limit iyerarxiyası müxtəlif ədədlər toplusu deyil, qərar qəbul edən sistemdir. Dəqiq spesifiklik və prioritet qaydası, vahid data modeli, düzgün tətbiq nöqtələri, idempotentlik və müşahidə limitləri tenantlara, bölgələrə və məhsullara görə ölçülən etibarlı təhlükəsizlik və uyğunluq dövrəsinə çevirir və böyüməyə mane olmur.