Comment fonctionne l'architecture backend du casino
1) Image complète : domaines et flux de données
Domaines clés :- Identity & Accounts - Inscription, authentification, rôles, appareils, sessions.
- Wallet & Ledger - comptes en espèces, portefeuilles bonus, transactions, ledger (append-only).
- Gaming & Bets - sessions de jeux, paris, rounds, calcul des résultats, intégration (RNG/Live/Crash, etc.).
- Bonuses & Promotions - Frispins, cashback, bons, wagering, anti-abyse.
- Payments (Cashier) - il-ramp/off-ramp : cartes, APM, crypta/steiblcoins, KYC-ancrage.
- KYC/AML/KYT & RG - Vérification de l'identité/de l'adresse/des revenus, contrôle des transactions, limites et délais.
- Risk & Compliance - limites de taux/de paiement, listes de sanctions, géo-blocage, audit.
- Catalogue & Lobby - liste des fournisseurs, jeux, catégories, limites ; A/B-Options.
- Reporting & BI - P&L, GGR/NGR, rétention, cycle de vie du joueur, affiliations.
- Observability & Ops sont des logs, des métriques, des traces, des alertes, des signaux frod.
Orchestration : la plate-forme moderne est construite par event-driven : les services échangent des événements via un bus (Kafka/NATS), les opérations critiques sont linéarisées (portefeuille/ledger), les sous-systèmes latéraux sont signés et réagissent de manière asynchrone (bonus, BI, notifications).
2) Modèle stratifié
Couche Edge : passerelle API, protection WAF/bot, limites de taux, filtres geo/IP, drapeaux de fonction.
Couche de service : microservices autonomes par domaine ; contrats synchrones - seulement lorsque vous avez besoin d'une consistance instantanée (par exemple, le débit du portefeuille à la mise).
Bus d'événements : principaux événements d'affaires ('bet. placed`, `round. settled`, `bonus. issued`, `kyc. verified`, `payout. requested`).
Données : OLTP (Postgres/MySQL) pour les transactions ; KV/Cache (Redis) pour les sessions/limites ; Un stockage objet (S3) pour les logs et les exportations ; OLAP (ClickHouse/BigQuery) pour l'analyse.
3) Portefeuille et ledger : le cœur de la plateforme
Principes :- Append-only ledger : chaque opération financière est un enregistrement avec le type, le montant, la monnaie, la référence de la source (pari, bonus, dépôt).
- Les soldes en espèces et en bonus sont espacés. Vous ne pouvez pas « mélanger » l'argent et les bonus ; la politique des sources de fonds est utilisée.
- L'atomicité est debet→kredit : taux = débit du portefeuille monétaire ou bonus + création de hold ; le calcul de la ronde retire hold et fait un crédit/débit sur le résultat.
- `LEDGER: HOLD` (−10. 00 EUR, source: cash, ref: betId)
- `LEDGER: SETTLE_DEBIT` (−10. 00 EUR) + `LEDGER: PAYOUT` (+36. 00 EUR) - si WIN
- `LEDGER: HOLD_RELEASE` (+10. 00 EUR) - si VOID/PUSH
- Opérations idempotentes (clés d'idempotente par "requestId').
- Versioner l'équilibre (verrouillage optimiste) pour se protéger des courses.
- Une monnaie claire de calcul et de fixation des taux de change lors des conversions.
4) Intégrations avec les fournisseurs de jeux
Modèles de portefeuille :- Seamless est l'équilibre de l'opérateur ; le pari/calcul passe par notre API en temps réel.
- Transfer - dépôt à la banque du jeu auprès du fournisseur ; plus de friction, mais en dessous de l'exigence de portefeuille pharmacie.
- `bet. place '→ pre-auth dans le porte-monnaie (hold) →' acceptée/référée '.
- `round. settle 'du fournisseur (webhook/WS) → settle dans le ledger → un événement dans le bus → un rapport/bonus.
Standardisation via bridge : schémas d'événements uniques et identifiants 'roundId/betId', table de mappage des limites et side-bets, normalisation des erreurs.
5) Bonus, wagering et anti-abyse
Modèles : bonus de dépôt, frispins, retours (cashback), missions, tournois.
Wagering : les progrès du pari sont stockés séparément ; la règle du « quel taux compte » (intérêts par catégorie de jeu).
Priorité à la radiation : d'abord les fonds bonus, puis réels - ou vice versa, strictement politiques.
Les anti-modèles du joueur : parier sur les résultats opposés, les paris minimaux pour le phare du progrès, le transfert entre les jeux avec des poids différents - sont pris par les règles et le scoring.
6) KYC/AML/KYT и Responsible Gaming (RG)
KYC : vérification de l'ID/adresse/âge ; les statuts gèrent les limites (deposit/withdraw/betMax).
AML/KYT : contrôle des canaux de paiement et des adresses en ligne (pour la crypte), listes de sanctions, sources de fonds.
RG : limites journalières/hebdomadaires, délais d'exécution, auto-exclusion ; les contrôles de blocage sont effectués avant 'bet. place` и `payout. request`.
7) Caisse : Dépôts et paiements
Dépôts : fournisseurs de cartes/ARM, cryptes/stablets, méthodes locales ; Webhook-confirmations ; protection contre les risques charjbec.
Paiements : files d'attente, limites, principe à 4 yeux pour les sommes importantes ; les sources de fonds → « uniquement le solde cash ».
Il-ramp/off-ramp crypta : auto-conversion, adresses KYT, couverture d'exposition.
8) Limites, risques et réglementations régionales
Profils de limite ('DEFAULT', 'VIP _ A', 'VIP _ B', 'ULTRA') par pays/devise/KUS.
Géo-blocage par IP/GPS/document.
Chevauchements par jeu/catégorie, interdictions des fournisseurs dans les juridictions.
Réponse aux anomalies : surtensions tarifaires, corrélation appareils/paiements, beaucoup de « VOID » d'un seul utilisateur.
9) Observabilité et exploitation
Métriques : retards de portefeuille, refus de paris, temps de calcul du tour, conversion des depozita→stavka, GGR/NGR, paiement des SLA, part des taux de bonus.
Logs et traces : corrélation 'traceId'dans tous les événements ; stockage des événements bruts dans un entrepôt « froid ».
Alert : dégradation de la réponse du portefeuille, sursaut de 'VOID', erreur de reconcile des rapports, croissance de 'RG _ BLOCKED'.
Runbooks : procédures claires pour les incidents (chute du fournisseur, dissynchrone du ledger, annulation des rounds).
10) Sécurité et vie privée
Auth : JWT/opaque tokens, rotation des clés ('kid'), mTLS vers les intégrations critiques.
Politiques d'accès : répartition rigoureuse des rôles (opérations, finances, sapport), 2FA ; pour les gros paiements - OK de la deuxième personne.
Confidentialité des données : cryptage PII, tokenisation des données de paiement, minimisation du stockage ; RGPD/suppression sur demande.
Audit : journaux immuables, signature d'événements critiques, exportation pour le régulateur.
11) Évolutivité et tolérance aux pannes
Les services Statles derrière l'auto-scaler ; une boule horizontale pour les tables chaudes (paris, logs d'événements).
Ledger - réserve verticale + réplication pour la lecture/rapport ; « geler » les schémas de migration via les tables shadow.
Mise en cache : Redis avec TTL et stratégies « bi-checks » (read-through + invalidate par évènement).
DR/HA : multi-AZ, backups à récupération régulière, RPO/RTO au niveau des exigences réglementaires.
Modes de degradation : caisse autonome, désactivation des bonus « lourds », traduction des jeux en direct en maintenance lorsque le pneu n'est pas disponible.
12) Contrats et exemples
Taux (sync, JSON/REST ou gRPC) :json
POST /bets/place
{
"requestId": "9a7f-…", "playerId": "p_123", "wallet": "cash",
"roundId": "R-2025-10-17-19:20:05-PRAGM-Table12", "gameId": "pragm_live_roulette", "selection": [{"market":"straight","value":"17"}], "stake": {"amount":"10. 00","currency":"EUR"}, "device": {"ip":"203. 0. 113. 5","ua":"Mozilla/..."}
}
Réponse :
json
{
"status": "ACCEPTED", "betId": "bet_8cd…", "balanceAfter": "245. 30", "hold": "10. 00", "limits": {"maxBet":"5000. 00"}
}
Événement dans le bus (async) :
json
{
"event":"round. settled", "roundId":"R-2025-10-17-19:20:05-PRAGM-Table12", "bets":[{"betId":"bet_8cd…","outcome":"WIN","stake":"10. 00","payout":"360. 00"}], "playerId":"p_123", "ts":"2025-10-17T19:20:09. 231Z", "traceId":"tr_5f1…"
}
13) Anti-modèles (ce qui brise la plateforme)
Mélange de bonus et d'argent en une seule transaction sans source.
Tokens à longue durée de vie et stockage sur le client.
Manque d'idempotence dans les opérations critiques (prises de débit).
Rapport monolithique SQL sur les bases de données de combat (OLAP contre OLTP).
Procuration aveugle au fournisseur sans reconcile ni limites.
Pas de Time Standard (UTC partout !) dans les identificateurs de round et les rapports.
Les appels synchrones dans les domaines non financiers (bonus/notifications) bloquent le pari.
14) Chèque de démarrage backend casino
Finances et portefeuille
- Ledger append-only, idempotence, version du bilan.
- Séparation cash/bonus, politique des sources.
- Les cours/conversions sont fixés lors de l'opération.
Intégration des jeux
- Contrat de pari/règlement unique, format « roundId/betId ».
- Portefeuille seamless par défaut ; Transfer - seulement là où il est justifié.
- Scripts VOID/REFUND automatiques.
KYC/AML/RG
- Politiques avant l'admission au taux/paiement ; les statuts de KYC ↔ des limites.
- KYT pour la chaîne, le dépistage des sanctions, le stockage de la base de données probantes.
La caisse
- Webhooks/signatures, prises/retraits, reconcile avec les fournisseurs de PSP/crypto.
- 4-yeux pour les gros paiements, journal des actions des opérateurs.
Observabilité
- Métriques de portefeuille, round-settle latency, refus de paris, SLA de paiement.
- Les traces sont de bout en bout (traceId), alertes, runbooks.
Sécurité
- mTLS/HMAC, JWT avec TTL court, rotation des clés.
- Rôles/droits, 2FA, Tokenization des données de paiement.
Données
- Division OLTP/OLAP, CDC en DWH, S3 pour les événements bruts.
- Backaps et tests de récupération réguliers.
15) Résultat
L'architecture backend casino est un noyau strict d'argent et de paris avec une cohérence linéaire et une périphérie flexible sur les événements : bonus, analyse, communications. Le succès n'est pas déterminé par le nombre de microservices, mais par la discipline : limites de domaine claires, ledger sans « magie », idempotence, observabilité et conformité par défaut. Avec cette base, la plate-forme s'adapte par pays/devises/fournisseurs et résiste aux charges sans compromis sur la sécurité et l'argent.