Architecture casino core : couches, modules, bus de données

Texte intégral de l'article

💡 18+. Le matériel est éducatif. Pas un appel au jeu. L'objectif est de montrer une « carte de terrain » technique pour la construction ou l'audit du noyau iGaming.

1) Image entière : en quoi consiste le casino core

Casino core est un ensemble de services de domaine qui assurent l'enregistrement/identification des joueurs, la réception/stockage de l'argent, le calcul des taux, l'économie de bonus, le contrôle des risques et la conformité à la réglementation. Dans le schéma de haut en bas :

1. Couche Edge (périmètre externe) : passerelle API, WAF/bot defense, rate limiting, service-mesh ingress, filtres geo/légaux.

2. Domain-слой (бизнес-логика): PAM, Wallet/Ledger, Bonus Engine, Cashier/PSP Orchestration, Game Sessions, Risk/Anti-Fraud, RG, Jackpot/Tournaments, Affiliates, CRM/Notifications, Compliance/Reporting.

3. Couche de données/intégration : bus d'événements (Kafka/Pulsar), files d'attente (SQS/Rabbit), CDC/Outbox, ETL/ELT (dans les vitrines BI), Feature Store/ML, cache (Redis), OLTP OBD (Postgres/Oracle), OLAP (ClickHouse/BigQuery).

4. Observability & SecOps : metrics/tracing/logs, SIEM/SOAR, secrets (Vault/HSM), clés et tokens, RBAC/ABAC, journal d'audit (WORM).

2) Modules de domaine (composition minimale requise)

2. 1 PAM (Player Account Management)

Enregistrement/login, SSO, gestion des sessions et des périphériques, KBA/2FA.

Profil : âge/géo/monnaie/segments, statuts RG/auto-exclusion.

Restrictions : accès aux jeux par juridiction, bana, « chèques-réalité ».

2. 2 Wallet/Ledger (circuit monétaire)

Comptes multi-devises, double écriture (debit/credit), virements invariables.

Transactions atomiques de paris et de gains (clés d'identité, exactly-once dans le domaine).

Holds sous dos/tours actifs ; les comptes de transit du jackpot.

Interaction uniquement via les commandes (commande API), lecture via les projections (CQRS).

2. 3 Cashier / PSP Orchestration

Routage des paiements par bande géographique/bande binaire/scoring ; cascade en cas de défaillance.

3-DS/AVS/velocity-rules ; Tokénisation des cartes ; on-/off-ramp pour la crypta.

SLO Set : autorisation ≤ 3c p95, succès global du dépôt ≥ 85 % par géo.

2. 4 Sessions de jeu (intégrations avec les fournisseurs)

Création de sessions de jeu (token handshake), validation pays/monnaie/âge.

Les événements se déroulent stavka→iskhod→settlment sur le bus ; Le RNG et le calcul sont du côté du fournisseur.

Anti-abyse : min bet, fréquence des spins, interdiction de changer la dénomination « à l'intérieur du trick ».

2. 5 Bonus Engine

Steats bonus (issued/locked/active/forfeit), wager, contribution par jeu, max bet/max cashout, debline.

Missions/quêtes, frispins, cashback ; compatible avec les tournois/jackpots.

La validité rigide des règles au moment du pari ; une histoire immuable.

2. 6 Risk / Anti-Fraud

Signaux comportementaux (taux de mise, multi-comptes, appareils/cartes partagés).

Règles de velocity, vérification graphique des liens, chargeback defense.

Réactions : douces (limites), rigides (bloc/escalade en AML).

2. 7 Responsible Gambling (RG)

Limites de dépôt/perte/taux/temps, délais, auto-exclusion.

« La réalité-chèques » et les pauses forcées ; stockage des consonnes et des loges.

2. 8 Jackpots & Tournaments

Local/réseau, fix/progression ; un prélèvement de participation à chaque taux.

Leaders publics ; Vérification indépendante des résultats ; anti-bot.

2. 9 Affiliates & CRM

Tracking sous-ID, attribution (CPA/RevShare/Hybrid), postbacks.

Segmentation, déclencheurs, suppression-règles, omnicanal (push/e-mail/SMS).

2. 10 Compliance & Reporting

Déchargement réglementaire, rapports fiscaux, SAR/STR ; audit-log WORM.

Résidence de données par juridiction (UE/UK/BR, etc.).

3) Modèle d'événement et bus de données

3. 1 Points de base (exemple Kafka-neuming)

`player. registered`, `player. kyc. status. changed`

`wallet. debit. requested/committed/failed`, `wallet. credit.`
`game. session. started/ended`, `bet. placed`, `bet. settled`
`bonus. issued/consumed/forfeited`, `wager. progress. updated`
`rg. limit. hit`, `rg. timeout. started/ended`
`cashier. deposit. requested/succeeded/failed`, `withdrawal. requested/sent`
`risk. alert. raised/closed`, `aml. case. opened`
`jackpot. contribution/triggered`, `tournament. score. updated`

Contrats : Avro/JSON Schema + Schema Registry, versioning (backward compatible), clés d'idempotence strictes.

3. 2 Modèle d'événement (simplifié)

json
{
"event_id": "uuid",  "event_type": "bet. settled",  "occurred_at": "2025-10-23T16:09:12Z",  "tenant_id": "brand-1",  "player_id": "p_123",  "session_id": "s_456",  "trace_id": "t_abc",  "payload": {
"game_id": "provider:slot_777",   "bet_amount": {"amount": 2. 00, "currency": "EUR"},   "win_amount": {"amount": 36. 40, "currency": "EUR"},   "bonus_impacted": true
}
}

Règle : événements - immuables ; ajustements - par des événements compensateurs distincts.

3. 3 Outbox & CDC

Toutes les transactions de domaine écrivent l'événement dans l'outbox dans la même base de données → le pablisher de fond envoie dans le bus.

CDC (Debezium et analogues) - pour les flux secondaires dans DWH sans charge sur OLTP.

4) Consistance, sagas et idempotence

Sagas pour les processus longs (dépôt/cache, vérification, récompenses de tournoi).

Idempotence de toutes les commandes : 'Idempotency-Key' + déduplication côté service.

Stratégie de cohérence : dans le portefeuille - strictement (ACID), sinon - eventual (via projections).

Compensation : événements de domaine individuels, interdiction des « modifications manuelles » dans le ledger.

5) Données : OLTP/OLAP, caches, projections

OLTP : Postgres/Oracle pour portefeuille, PAM, bonus (p95 <150 ms).

Caches : Redis pour les sessions, les limites, les projections chaudes de leaders.

OLAP: ClickHouse/BigQuery — витрины KPI (FTD, NGR, ARPPU, Retention, LTV, Wager progress, Risk flags).

Projections (CQRS) : recherche rapide par joueur/transaction (<2c), barre de temps réel RG/risque.

6) Orchestre payant : Plus détaillé

Règles d'itinérance : géo, BIN, risque, charge, coût.

Cascade : PSP1 → PSP2 sans perte de panier ; Retrai avec pause exponentielle.

Rapprochements : rapports quotidiens de PSP → registre du portefeuille ; les différences automatiques → les tiquets.

7) Intégrations avec les fournisseurs de jeux

Modèle Gateway : API de jeu unique, mapping devises/fiches, chèque santé avec dégradation.

Settlment : le collbec entrant du fournisseur → la commande de domaine wallet. settle avec la clé d'idempotence.

Verrous : minimum ; le pari/gain est une paire atomique de câblage.

8) Observabilité et SLO

Метрики: p95/p99 latency per service, error rate, saturation, business KPIs (bets/min, settle lag, deposit success).

Trace : trace_id de bout en bout (edge→domeny→shina→konsyumery).

Logs : structurés, avec édition PII.

SLO-minimum :

L'aptame du noyau ≥ 99,95 %
p95 portefeuille <150 ms
Settlements perdus/dupliqués = 0
Temps de retard des événements jusqu'à BI <5 min

9) Sécurité et conformité

Zero-trust : mTLS à l'intérieur du mesh, jetons à courte durée de vie, RBAC/ABAC, principe des droits les plus faibles.

Secrets : Vault/HSM, rotation des clés, cryptage KMS des données "at rest'.

PCI DSS/GDPR/analogies locales : segmentation des environnements, tokenisation PAN, DLP, journal d'accès (WORM).

Protection WAF/bot : filtres par signaux comportementaux, device-fingerprinting.

Résidence de données : Chardonnages par région ; interdiction des PII intersectoriels.

10) Disponibilité, DR et version des versions

Actif/actif/passif par région ; RPO ≤ 5 min, RTO ≤ 30 min.

Versions canaries/drapeaux de fonction, annulations ; migrations OBD - via ghost/index secondaires.

Ingénierie du chaos : feel régulier des réseaux/PSP/fournisseurs pour vérifier la dégradation.

11) Gestion des schémas et de la qualité des données

Contrats de données : versioning d'événements (semver), tests contractuels de producteurs/consumers.

Goverance : catalogue de données (data catalogue), niveau de confiance dans les sources, mise à jour SLA des vitrines.

Qualité : déduplication, événements tardifs (late arrivals), idempotent upserts dans OLAP.

12) Rôles et accès (Back-office)

RBAC : rôles clairs (finances, risques, sapport, marketing, conformité).

Action Crète : confirmation « 4 yeux », journal des opérations immuables.

Écran PII : masquage ; accès complet - sur demande/tokens temporaires.

13) Métriques de maturité casino core (autoévaluation)

1. Fiabilité : SLO portefeuille/caisse/sessions sont effectuées ≥ 99 % des jours.

2. Données : les événements entrent dans la BI ≤ 5 min ; consistance ledgers vs PSP ≥ 99,99 %.

3. Bonus : concepteur de règles sans édition OBD ; audit des changements.

4. RG/AML : signaux temps réel ; les rapports/décharges sont automatisés.

5. Incidents : MTTR <30 min ; les postmortems sont publics en interne.

6. Tests : contrats, charges, tests de chaos ; sandbox de test des fournisseurs/PSP.

14) Chèque du vérificateur de l'architecture

Il y a outbox/CDC, l'événement est publié atomiquement avec la transaction.
Ledger est réalisé comme un livre de câblage immuable ; il y a un rapprochement avec le PSP.
Toutes les commandes sont idempotentes ; il y a une déduplication sur les clés.
Séparés par OLTP et OLAP ; les projections ne frappent pas les OBD de combat.
Les limites RG s'appliquent de façon synchrone au tarif ; reality-check est forcé.
La passerelle de jeu est dégradée en read-only/ » no new sessions » en cas d'incident.
Le plan DR est régulièrement mis en œuvre ; les backups sont testés par récupération.
La politique sur les clés/secrets et leur rotation est documentée.
Les rapports de conformité sont collectés automatiquement (pas de travail manuel Excel).
Logs d'audit - WORM, accès selon le principe des droits les plus bas.

15) Anti-modèles (« drapeaux rouges »)

Édition manuelle des balances et des bonus dans la base de données.

Mélange d'API publiques et privées, pas de passerelle API.

Enregistrement des événements « contournant » les transactions de domaine (pas via outbox).

Portefeuille monolithique et bonus sans idempotence et saga.

Une base de données unique « pour tout » + demandes BI selon le schéma de combat.

Pas de versioning d'événements et de tests contractuels.

Il n'y a pas de registre de modification des règles de bonus et des formules de tournoi.

Pannes de paiement sans cascade ; « essayez plus tard » comme stratégie.

Pas d'outils RG hors de la boîte ; licence de confiance.

Casino core est un événement, strictement limité par les droits du « réseau » de services, où l'argent et la responsabilité sont primaires. L'architecture forte repose sur trois piliers :

1. Intégrité rigide de l'argent (ledger, idempotence, sagas, outbox/CDC), 2. Evénement et observabilité (contrats, traçage, SLO, vitrines BI), 3. Sécurité et conformité par défaut (zero-trust, PCI/GDPR, RG/AML).

En construisant ces bases, l'opérateur met à l'échelle le contenu, l'économie bonus et le marketing sans risque pour le principal - l'argent des joueurs et la réputation de la marque.