Hiérarchie des limites

Une limite est une limite formelle de l'activité en temps/volume/coût. Dans iGaming et fintech, les limites sont la base de la sécurité, de la conformité et de la gestion des risques. La hiérarchie des limites définit dont la règle est supérieure et où elle est exécutée pour éviter le double coût, le dépassement des paris/dépôts, l'abus de bonus et les violations du jeu responsable.

1) Classification des limites

Par la force d'application

Hard - insurmontable (interdiction de l'opération).
Soft - avertissement/friction (captcha, confirmation), escalade à dur à répétition.

Par nature

En espèces : montant du dépôt/taux/paiements ; limites journalières/hebdomadaires/mensuelles.
Temps : durée de la session, pauses, « refroidissement », délais.
Quantitatif : nombre de transactions, spins, requêtes API.
Vitesse (taux limites) : RPS/concurrence.
Quotas : budget d'action par guichet (N par jour/semaine).
Contextuel : par jeu/fournisseur/méthode de paiement/appareil/pays.

Par propriétaire

Réglementation/marque (tenant/région)

Système (plateforme, protection de l'infrastructure)

Personnalisé (self-limits dans RG)

2) Mesures et clés (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

Plus la clé est précise, plus la priorité est élevée (voir la hiérarchie ci-dessous).

3) Hiérarchie et priorités (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)

• Un contexte plus étroit chevauche un contexte large : player> region.
• N'importe quel deny évident gagne allow.
• Les conflits soft/hard sont résolus en faveur du hard.
• La valeur minimale autorisée (min-cap) est gagnée avec les quotas/fenêtres.

4) Modèle de données (simplifié)

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 : toutes les opérations portent "opération _ id' ; l'incrémentation du compteur est effectuée une seule fois (inbox/outbox ou compare-and-swap selon la version).

5) Algorithme d'évaluation (evaluation)

1. Collecte des candidats par 'kind'et croisement par' scope '.
2. Classement par spécificité (nombre de mesures coïncidant) et « priorité ».
3. Paramètres de merge : raideur (dur> soft), min-cap, min-window.
4. Vérification des quotas/limites de rate : Token baquet (RATE) + fix/fenêtre glissante (QUOTA).
5. Решение: `ALLOW | SOFT_WARN | DENY` + `retry_after`/`remaining`.
6. Enregistrement de la trace : audit de l'événement et métrique.

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) Points d'application (points d'enfouissement)

API Gateway - Protection de l'infrastructure : RATE (RPS), CONCURRENCY, burst.
Services de domaine - limites sémantiques : dépôts, paris, paiements, sessions.
Adaptateurs de fournisseur - les limites de fournisseur dupliquées/locales (valider avant l'appel).
Client UX - conseils préventifs (SOFT), « N'restant », minuteries.

Règle : nous débitons un quota/tokens une fois - là où l'opération devient irréversible (après réservation du portefeuille/étape authentifiée validée).

7) Limites monétaires : dépôt/taux/paiement

Per currency : conservez les limites dans la devise de l'opération, pas via FX « à la volée ».
Min/Max: `min_bet`, `max_bet`, `max_payout_single`.
Fenêtres : 'deposit _ daily/weekly/monthly' avec des limites fixes (par exemple dans le temps de licence).
Composition : plage totale autorisée = intersection (régionale ∩ de marque ∩ personnalisée).

8) Jeu responsable (RG)

Self-limits (le joueur a posé lui-même) est toujours plus dur que les marques.
Contraintes de temps : 'session _ durée', 'cool _ off', 'self _ exclusion'.
Escalade : dépassement de la limite soft → avertissement, répétition → dur (dans la fenêtre).
Vérification : Chaque changement de RG est enregistré de manière non permanente (qui/quand/pourquoi).

9) Rate limit vs Quota : quand quoi

Rate limit (token-bucket/leaky) : protection contre les surtensions ; appliquer sur gateway/adaptateurs.
Quota (fixed/sliding window) : gérer le budget total action/argent ; appliquer dans le domaine (deposit_daily, bet_count_hourly).
Souvent utilisés ensemble : 'RATE' (pics instantanés) + 'QUOTA' (budget journalier).

10) Multi-tenant et multi-région

Les limites contiennent toujours 'tenant _ id' et 'region/licence'.
Résidence : compteurs et stockage - dans la région « maison ».
Fairness : séparez les pools RATE/QUOTA per tenant afin que le « bruyant » ne perturbe pas les SLO des autres.

11) Idempotence et consistance

Commandes avec 'operation _ id' ; la répétition ne doit pas augmenter 'consumed'.
Pour l'argent - strict path : réserve de portefeuille et incrément counters dans une transaction/saga (TCC).
Pour RATE - Utilisez les incréments/entrepôts atomiques la fenêtre actuelle.

12) Observabilité

• `limit_eval_p95_ms`, `decision_rate{ALLOW,DENY,SOFT}`,
• « quota _ remaining _ percent » par espèce principale,
• `rate_throttled`, `burst_dropped`,
• `rg_self_limit_hits`, `regulatory_hits`.

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

Alert : croissance de 'DENY '/' 429' au-delà du seuil, réalisation fréquente des caps de régulation, « hot key » par joueur/appareil.

13) Versioning et audit

Chaque règle est avec 'valid _ from/valid _ to', 'created _ by', 'reason _ code'.
События: `LimitCreated/Updated/Deleted`, `LimitHit`, `LimitDenied`.
Conservez un « instantané » des règles actives pour lire les décisions historiques (dispute-ready).

14) Tests

Tests de contrat : schéma et mesure des spécificités/priorités.
Property-based : « most specific wins », « deny gagne allow », « min-cap ».
Golden cases : ensemble de conflits de référence (tenant vs région, RG vs marque).
Chaos : sursaut de demandes (RATE), course aux compteurs, répétition des équipes (idempotence).
E2E : matching des limites sur les chèques du régulateur (dépôt/semaine/mois).

15) Pleybooks

1. Tempête 429/throttling sur gateway

Réduire la concurrence, augmenter temporairement le token-baquet, activer la hiérarchisation des chemins critiques, analyser les sources (ASN/IP).

2. Refus massifs en vertu de la limite réglementaire

Vérifier la planification des fenêtres et du temps ; prolonger le soft-UX (explications), notifier la conformité.

3. Faux refus positifs à cause des courses

Activer la sérialisation par la clé 'player _ id/kind'et passer à CAS/dedup par 'operation _ id'.

4. Divergence avec la limite du fournisseur

Synchroniser min/max per game, ajouter une pré-validation à l'adaptateur, abaisser temporairement le répertoire/le jeu de lecture.

16) Erreurs typiques

L'absence de hiérarchie → « glisser la corde » entre les règles.
Calcul des limites dans l'interface utilisateur sans validation de serveur.
Remplacer les quotas par des limites de vol (et vice versa).
Ignorer les monnaies/étapes aux limites monétaires (CLP/JPY).
Il n'y a pas d'idempotence → double annulation du quota.
Un pool RATE unique sur tous les tenants → le sheiring des problèmes.
L'absence d'audit ne peut → expliquer le refus.

17) Recettes rapides

Acceptation du pari : 'max _ bet' = min (région, jeu, fournisseur, RG personnalisé) ; RATE sur '/bets. place '= 20 rps/player, QUOTA = 500 paris/jour.
Dépôts : 'deposit _ daily/monthly' + 'deposit _ single' ; avant de valider les limites PSP.
Sessions : 'session _ duration' hard + rappels toutes les N minutes (soft).
Protection API : TAUX global par clés 'ip _ asn'et' tenant _ id' ; Fenêtres canaries pour les sorties.

18) Chèque-liste avant la vente

• La hiérarchie de spécificité et la politique de Merge (most specific wins, deny> allow) sont fixées.
• Modèle de données avec 'scope', 'kind',' type ', fenêtres, devises et priorités.
• Points d'application : gateway (RATE), domaine (QUOTA/argent), adaptateurs (fournisseurs).
• Idempotence ("opération _ id') et sérialisation par clé ; les compteurs sont atomiques.
• Observabilité : métriques des solutions, lagunes des fenêtres, alertes ; trace avec 'matched _ limit _ id'.
• Versioning et vérification inaltérable des changements et des résultats.
• Paquet de test : contract/property/golden/chaos/E2E.
• Multi-tenant fairness et data residency respectés.
• UX pour les limites SOFT : messages compréhensibles, 'remaining/retry _ after'.
• Les pleybooks des incidents sont harmonisés avec la conformité et le soutien.

Conclusion

La hiérarchie des limites est un système de décision, pas un ensemble de nombres disparates. Une spécificité et un ordre de priorité clairs, un modèle de données unique, les bons points d'application, l'idempotence et l'observabilité transforment les limites en un circuit de sécurité et de conformité fiable qui s'adapte aux tenants, aux régions et aux produits - et n'empêche pas la croissance.