Gerarchia dei limiti

Il limite è un limite di transazione formalizzato in tempo/volume/costo. Nel iGaming e nel fintech, i limiti sono la base per la sicurezza, la conformità e la gestione dei rischi. La gerarchia dei limiti stabilisce la cui regola è più importante e dove viene eseguita per evitare il doppio spreco, il superamento dei tassi/depositi, i bonus abusivi e le violazioni del gioco responsabile.

1) Classificazione dei limiti

Per la forza d'uso

Hard - insormontabili (proibizione dell'operazione).
Soft - Avviso/frizione (goccia, conferma), escalation a hard quando ripetuto.

Per natura

Denaro: importo deposito/tasso/pagamento; limiti diurni/settimanali/mensili.
Temporali: durata della sessione, interruzioni, raffreddamento, timeout.
Quantitativo: numero di transazioni, spin, richieste API.
Velocità (rate limits): RPS/competitività.
Quote: budget azioni per finestra (N al giorno/settimana).
Contestuali per gioco/provider/metodo di pagamento/dispositivo/paese.

Per il proprietario

Regolatori/marchi (tenente/regione)

Sistema (piattaforma, protezione dell'infrastruttura)

Personalizzato (self-limits all'interno di RG)

2) Misure e chiavi (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

Più precisa è la chiave, maggiore è la priorità (vedere la gerarchia sottostante).

3) Gerarchia e priorità (not specific wins)

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

• Un contesto più stretto sovrappone l'ampio: player> region.
• Qualsiasi deny chiaro vince allow.
• I conflitti soft/hard si risolvono a favore dell'hard.
• Con le quote e le finestre, il valore minimo consentito (min-cap) vince.

4) Modello di dati (semplificato)

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

Idampotenza: tutte le operazioni portano «operation _ id»; il contatore viene eseguito una volta sola (inbox/outbox o compare-and-swap).

5) Algoritmo di valutazione

1. Raccolta dei candidati per «kind» e «scope».
2. Classificazione specifica (numero di misurazioni corrispondenti) e «priority».
3. I parametri Merge sono rigidità (hard> soft), min-cap, min-window.
4. Controllo quote/rate limite - Token-Baquet (RATE) + Fix/Finestra di scorrimento (QUOTA).
5. Решение: `ALLOW | SOFT_WARN | DENY` + `retry_after`/`remaining`.
6. Registrazione traccia: controllo dell'evento e delle metriche.

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) Punti di applicazione (enforcement point)

API Gateway - Protezione dell'infrastruttura: RATE (RPS), CONCURRENCY, burst.
Servizi di dominio - limiti di significato: depositi, tassi, pagamenti, sessioni.
Gli adattatori di provider sono limiti di provider duplicati/locali (convalidati prima della chiamata).
X client - Suggerimenti preventivi (SOFT), N rimanente, timer.

Regola: cancelliamo una sola volta la quota/token, dove l'operazione diventa irreversibile (dopo aver prenotato il portafoglio/passo autenticato valida).

7) Limiti di cassa: deposito/tasso/pagamento

Per currency: memorizza i limiti nella valuta dell'operazione anziché tramite FX al volo.
Min/Max: `min_bet`, `max_bet`, `max_payout_single`.
Le finestre sono «deposit _ daily/week/monthly» con limiti fissi (ad esempio, in un timesone di licenza).
Composizione: intervallo totale risolto = intersezione ( regionali di brand).

8) Gioco responsabile (RG)

Self-limits (il giocatore ha impostato da solo) è sempre più duro di marchi.
Vincoli temporali: 'sessions _ duration', 'cool _ off', 'self _ exclusion'.
Escalation: superamento del limite soft, avviso, ripetizione hard (all'interno della finestra).
Controllo: ogni modifica RG viene registrata in modo non sicuro (chi/quando/perché).

9) Rate limit vs Quota: quando cosa

Rate limit (token-bucket/leaky) - Protezione contro i picchi; applica su gateway/adattatori.
Quota (fixed/sliding window): gestione del bilancio totale attività/denaro applica nel dominio (deposit _ daily, bet _ count _ houly).
Spesso usati insieme: «RATE» (picchi istantanei) + «QUOTA» (budget giornaliero).

10) Multi-tenente e multi-regione

I limiti contengono sempre tenant _ id e region/licence.
Residency, contatori e conservazione nella regione «domestica».
Fairness: separa i pool RATE/QUOTA per tenant in modo che «rumoroso» non distrugga lo SLO degli altri.

11) Idampotenza e consistenza

Comandi con'operation _ id '; la ripetizione non deve ingrandire «consumed».
Per il denaro - strict path - la riserva del portafoglio e l'incasso counters in una singola transazione/saga (TCC).
Per RATE - Usa gli involtini atomici/magazzini della finestra corrente.

12) Osservabilità

• `limit_eval_p95_ms`, `decision_rate{ALLOW,DENY,SOFT}`,
• 'queta _ remaining _ percent'per vista principale,
• `rate_throttled`, `burst_dropped`,
• `rg_self_limit_hits`, `regulatory_hits`.

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

Alert: altezza di DENY/' 429 "oltre la soglia, frequente raggiungimento di cappe regolatorie," hot key "per giocatore/dispositivo.

13) Versioning e controllo

Ogni regola è con'valid _ from/valid _ to ',' created _ by ',' reason _ code '.
События: `LimitCreated/Updated/Deleted`, `LimitHit`, `LimitDenied`.
Memorizzare «snapshot» delle regole attive per la riproduzione di soluzioni storiche (dispute-ready).

14) Test

Contract test - schema e misura specifiche/priorità.
Property-based: «not specific wins», «deny vince allow», «min-cap».
Golden case è un insieme di conflitti di riferimento (regione tenante vs, marchio RG vs).
Chaos: picchi di query (RATE), corse di contatori, ripetizione di comandi (idampotenza).
E2E: matching dei limiti sui listini degli assegni del regolatore (deposito/settimana/mese).

15) Playbook

1. Tempesta 429/throttling su gateway

Ridurre la concurrency, aumentare temporaneamente il token-baquet, attivare la priorità dei percorsi critici, analizzare le origini (ASN/IP).

2. Guasti di massa per il limite di regolazione

Controllare gli orari delle finestre e il timesone; Proroga soft-UX (spiegazioni), notifica la compliance.

3. Errori falsi positivi a causa delle corse

Attiva la serializzazione con la chiave «player _ id/kind», vai a CAS/Deduplicazione per «operation _ id».

4. Soluzione temporanea con il limite di provider

Sincronizza min/max per game, aggiungi pre-convalida all'adattatore, abbassa temporaneamente la directory/playcam del gioco.

16) Errori tipici

Nessuna gerarchia per trascinare il filo tra le regole.
Calcola i limiti dell'UI senza validazione server.
Sostituzione di quote con limiti di rate (e viceversa).
Ignora valute/passaggi a limiti di cassa (CLP/JPY).
Nessuna idepotenza. Doppia cancellazione della quota.
Un unico pool di RATE su tutti i tenenti ha un problema di sharing.
La mancanza di controllo non può essere spiegata.

17) Ricette veloci

Accetta la puntata: «max _ bet» = min (regione, gioco, provider, RG personalizzato); RATE a '/bets. place '= 20 rps/player, QUOTA = 500 scommesse/giorno.
Depositi: 'deposit _ daily/monthly' +' deposit _ single '; pre-validare i limiti PSP.
Sessioni: 'sessions _ duration' hard + avvisi ogni N minuti (soft).
Protezione API: RATE globale in chiave «ip _ asn» e «tenant _ id»; finestre canarie per i rilasci.

18) Foglio di assegno prima della vendita

• La gerarchia di specificità e il criterio di merge sono fissati.
• Modello di dati con «scope», «kind», «type», finestre, valute e priorità.
• Punti di applicazione: gateway (RATE), dominio (QUOTA/money), adattatori (provider).
• Idampotenza ('operation _ id') e serializzazione delle chiavi; contatori di atomoni.
• Osservabilità: metriche di soluzioni, lame di finestre, alert; traccia con'matched _ limit _ id '.
• Versioning e controllo invariato delle modifiche e degli effetti.
• Pacchetto di prova: contract/property/golden/chaos/E2E.
• Il multi-tenant fairness e data residency sono stati rispettati.
• UX per i limiti SOFT: messaggi comprensibili, 'remaining/retry _ after'.
• I playbook degli incidenti sono coerenti con la compliance e il supporto.

Conclusione

La gerarchia dei limiti è un sistema decisionale, non un insieme di numeri separati. La precisione e l'ordine delle priorità, il modello di dati unificato, i punti di applicazione corretti, l'idipotenza e l'osservabilità trasformano i limiti in un tracciato affidabile di sicurezza e conformità scalabile in base a tenanti, regioni e prodotti, senza ostacolare la crescita.