Hiyerarşiyi sınırlama

Limit, bir işlemin zaman/hacim/değer cinsinden resmi bir sınırlamasıdır. IGaming ve fintech'te sınırlar güvenlik, mevzuata uygunluk ve risk yönetimi için temel oluşturur. Limit hiyerarşisi, çifte harcamayı, bahisleri/depozitoları aşmayı, bonusların kötüye kullanılmasını ve sorumlu oyun ihlallerini önlemek için kimin kuralının en önemli olduğunu ve nerede uygulandığını belirtir.

1) Sınırların sınıflandırılması

Uygulama gücü ile

Sert - aşılmaz (operasyon yasağı).
Yumuşak - uyarı/sürtünme (captcha, onay), tekrarlandığında sertliğe tırmanma.

Doğası gereği

Nakit: depozito tutarı/oranları/ödemeleri; Günlük/haftalık/aylık limitler.
Zaman: oturum süresi, molalar, "soğutma", zaman aşımları.
Kantitatif: işlem sayısı, spinler, API istekleri.
Hız limitleri: RPS/rekabet.
Kotalar: Pencere başına eylem bütçesi (N/gün/hafta).
Bağlamsal: oyun/sağlayıcı/ödeme yöntemi/cihaz/ülkeye göre.

Sahibinden

Düzenleyici/Marka (Kiracı/Bölge)

Sistem (platform, altyapı koruması)

Kullanıcı tanımlı (RG içinde kendi sınırları)

2) Ölçümler ve anahtarlar (kapsam)

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

Anahtar ne kadar doğru olursa, öncelik o kadar yüksek olur (aşağıdaki hiyerarşiye bakın).

3) Hiyerarşi ve öncelikler (en spesifik kazançlar)

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

• Daha dar bir bağlam geniş bir alanla çakışır: oyuncu> bölge.
• Herhangi bir açık inkar kazanır izin.
• Yumuşak/sert çatışmalar sert lehine çözülür.
• Kotaların/pencerelerin birleştirilmesiyle, izin verilen minimum değer (min-cap) kazanır.

4) Veri modeli (basitleştirilmiş)

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: tüm işlemler 'operation _ id' taşır; Sayaç artışı bir kez gerçekleştirilir (gelen kutusu/giden kutusu veya versiyona göre karşılaştır ve değiştir).

5) Değerlendirme algoritması

1. Adayları'tür've 'kapsam'ı geçerek toplamak.
2. Spesifikliğe göre sıralama (eşleşen ölçümlerin sayısı) ve 'öncelik'.
3. Parametre aralığı: sertlik (sert> yumuşak), min-cap, min-window.
4. Kotaları/oran sınırını kontrol edin: token-bucket (RATE) + fix/sliding window (KONTENJAN).
5. Решение: 'ALLOW | SOFT_WARN | DENY' + 'retry _ after'/' remaining'.
6. İzleme kaydı: denetim olayı ve metrikler.

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) Uygulama noktaları

API Ağ Geçidi - altyapı koruması: RATE (RPS), CONCURRENCY, burst.
Alan adı hizmetleri - anlamsal sınırlar: mevduat, oranlar, ödemeler, oturumlar.
Sağlayıcı adaptörleri - yinelenen/yerel sağlayıcı sınırları (aramadan önce doğrulayın).
İstemci UX - önleyici istemler (SOFT), "N sol", zamanlayıcılar.

Kural: Kotayı/jetonları bir kez yazın - işlemin geri döndürülemez hale geldiği yer (cüzdan/geçerli kimlik doğrulaması adımını yedekledikten sonra).

7) Nakit limitleri: depozito/oran/ödeme

Para birimi başına: İşlem para biriminde mağaza limitleri, anında FX üzerinden değil.
Min/Max:'min _ bet ',' max _ bet ',' max _ payout _ single '.
Windows: Sabit sınırları olan 'deposit _ daily/weekly/monthly' (örneğin, lisans zaman diliminde).
Kompozisyon: son izin verilen aralık = kesişme (bölgesel ∩ marka ∩ özel).

8) Sorumlu Oyun (RG)

Kendi sınırları (oyuncunun kendisine sorduğu) her zaman markalı olanlardan daha zordur.
Zaman sınırları: 'Session _ duration', 'cool _ off', 'self _ exclusion'.
Eskalasyon: yumuşak sınırın aşılması - uyarı, sert tekrarlama - (pencerenin içinde).
Denetim: Her RG değişikliği yanal olmayan (kim/ne zaman/neden) kaydedilir.

9) Oran limiti vs Kota: ne zaman

Hız sınırı (token-bucket/leaky): dalgalanma koruması; Ağ geçidi/adaptörlere uygulanır.
Kota (sabit/sürgülü pencere): toplam eylem/para bütçesini yönetmek; Etki alanına uygula (deposit_daily, bet_count_hourly).
Genellikle birlikte kullanılır: 'ORAN' (anlık zirveler) + 'KOTA' (günlük bütçe).

10) Çok kiracı ve çok bölgeli

Sınırlar her zaman 'tenant _ id've' bölge/lisans 'içerir.
İkamet: sayaçlar ve depolama -'ev "bölgesinde.

Adalet: Kiracı havuzları başına ayrı RATE/KOTA, böylece "gürültülü" başkalarının SLO'larını bozmaz

11) Idempotency ve tutarlılık

'Operation _ id' komutları; Tekrar 'tüketilen' artırmamalıdır.
Para için - kesin yol: bir işlemde/destanda (TCC) cüzdan rezervi ve artım sayaçları.
RATE için - atomik artışlar/depolar mevcut penceresini kullanın.

12) Gözlemlenebilirlik

• 'limit _ eval _ p95 _ ms', 'decision _ rate {ALLOW, DENY, SOFT}',
• Ana türlere göre 'quota _ remaining _ percent',
• 'rate _ throttled', 'burst _ drop',
• 'rg _ self _ limit _ hits', 'regulatory _ hits'.

Логи/трейсинг: 'matched _ limit _ id', 'scope _ hash', 'operation _ id', 'window _ start/reset', 'remaining'.

Uyarılar: Eşik üzerinde 'DENY'/' 429' büyümesi, düzenleme kapaklarının sık sık elde edilmesi, oyuncu/cihaz tarafından "hot key".

13) Sürüm oluşturma ve denetleme

Her kural 'valid _ from/valid _ to', 'created _ by', 'reason _ code' şeklindedir.
События: 'LimitCreated/Updated/Deleted', 'LimitHit', 'LimitDenied'.
Tarihsel kararları yeniden üretmek için aktif kuralların "anlık görüntüsünü" tutun (anlaşmazlığa hazır).

14) Test etme

Sözleşme testleri: şema ve özellik/öncelik aralığı.
Mülkiyet tabanlı:'en spesifik kazançlar "," kazanı reddet izin ver ",'min-cap".
Altın durumlar: bir dizi referans çatışması (kiracı vs bölge, RG vs marka).
Kaos: Spike (RATE) isteyin, ırkları sayın, komutları tekrarlayın (idempotency).
E2E: regülatörün kontrol listesindeki limit eşleşmeleri (depozito/hafta/ay).

15) Oyun kitapları

1. Fırtına 429/ağ geçidinde kısma

Eşzamanlılığı azaltın, belirteç kovasını geçici olarak artırın, kritik yolların önceliklendirilmesini sağlayın, kaynakları analiz edin (ASN/IP).

2. Düzenleme sınırına göre toplu arızalar

Pencere zamanlamasını ve saat dilimini kontrol edin; Uzatılmış soft-UX (açıklamalar), uygunluğu bildirir.

3. Yarış nedeniyle yanlış pozitif başarısızlıklar

'Player _ id/kind' tuşu ile serileştirmeyi etkinleştir, 'operation _ id'ile CAS/dedup'a geç.

4. Sağlayıcı sınırı ile tutarsızlık

Oyun başına min/max eşitleyin, bağdaştırıcıya ön doğrulama ekleyin, oyun kataloğunu/yerleşimini geçici olarak düşürün.

16) Tipik hatalar

Hiyerarşi eksikliği: Kurallar arasında çekişme.
UI'de sunucu doğrulaması olmadan sınırların hesaplanması.
Kotaların oran sınırlarıyla değiştirilmesi (ve tersi).
Para birimlerini/parasal limitleri olan adımları göz ardı etme (CLP/JPY).
Idempotency yok - çift kota silme.
Tüm kiracılar için tek bir RATE havuzu - kesme sorunları.
Denetim yok - başarısızlık açıklanamaz.

17) Hızlı tarifler

Teklif kabulü: 'max _ bet' = min (bölge, oyun, sağlayıcı, kullanıcı RG); RATE on'/bahisleri. Yer '= 20 rps/oyuncu, KOTA = 500 bahis/gün.
Mevduat: 'deposit _ daily/monthly' + 'deposit _ single'; PSP limitlerini önceden doğrulayın.
Oturumlar: 'Session _ duration' hard + reminders every N minutes (soft).
API koruması: 'ip _ asn've' tenant _ id 'tuşlarıyla global RATE; Serbest bırakmak için kanarya pencereleri.

18) Satış öncesi kontrol listesi

• En özel kazançlar, inkar et> izin ver.
• 'Kapsam','tür ',' tür ', pencereler, para birimleri ve öncelikleri olan veri modeli.
• Uygulama noktaları: ağ geçidi (RATE), etki alanı (KOTA/para), adaptörler (sağlayıcı).
• Idempotency ('operation _ id') ve anahtarlarla serileştirme; Sayaçlar atomiktir.
• Gözlemlenebilirlik: çözüm metrikleri, pencere gecikmeleri, uyarılar; trace with 'matched _ limit _ id'.
• Değişikliklerin ve eylemlerin sürüm ve değiştirilemez denetimi.
• Test Paketi: contract/property/golden/chaos/E2E.
• Çok kiracılı adalet ve veri ikameti bir araya geldi.
• SOFT sınırları için UX: arkadaşça mesajlar, 'remaining/retry _ after'.
• Olay oyun kitapları uyum ve destek ile uyumludur.

Sonuç

Sınır hiyerarşisi bir karar sistemidir, bir dizi farklı sayı değildir. Açık özgüllük ve öncelik sırası, tek bir veri modeli, doğru uygulama noktaları, idempotans ve gözlemlenebilirlik, sınırları kiracılar, bölgeler ve ürünler arasında ölçeklendiren ve büyümeyi engellemeyen sağlam bir güvenlik ve uyumluluk döngüsüne dönüştürür.