Failover, réplication et plans DR pour les casinos

1) Objectifs commerciaux : RTO/RPO et flow critique

RTO (combien de temps le service peut ne pas être disponible) : login/pari/dépôt - secondes/minutes ; les rapports sont une horloge.

RPO (combien de données peuvent être perdues) : Portefeuille/transactions - ~ 0-30 secondes ; télémétrie - minutes.

Flow critique : login, dépôt/retrait, mise/mise, KYC/AML-saucisses, PSP/fournisseurs de jeux Web.

2) Modèles architecturaux de tolérance aux pannes

Active-Active (multi-région) : les deux régions gèrent le trafic ; RTO/RPO faible, consistance complexe.

Active-Standby : une région en activité, la deuxième est chaude ; État plus facile, RTO minutes.

Cell-based : isolation par « cellules » (market/brand), les incidents locaux ne font pas tout tomber.

Tarte Edge : Anycast CDN/WAF → passerelles régionales → clusters app → bases de données/caches répliquées.

3) Trafic-gestion et feelover réseau

Anycast + CDN/WAF : rachat de L3/4/7, chèque santé sur origin.

Failover DNS (TTL faible, multi-valeur), Gestionnaire de trafic/GSLB par métriques de santé.

Annonce BGP via un fournisseur anti-DDoS pour un changement de chemin rapide.

Chèque santé (exemple de logique) :

if p95_latency>threshold          5xx_rate>threshold          synthetic_login_fail:
drain(region_A); shift(traffic->region_B, ramp=5min)

4) Données : Portefeuille, commandes, paris

La source de la vérité est le journal du câblage (ledger) : seulement append, idempotence par "opération _ id'.

Harmonisation : jobs de reconnaissance périodiques entre ledger, PSP et fournisseurs de jeux.

Anti-prise : clés d'idempotency pour les dépôts/saucisses/paiements ; déduplication dans outbox/inbox.

5) Réplication OBD : options et compromis

Physique synchrone (semi-sync) : RPO minimum, risque de retards - appliquer par points (portefeuille).

Asynchrone : plus de performances/simplicité, RPO secondes-minutes - sous métadonnées de jeu, guides.

Logique (CDC → flash vers une autre région) : sélectivité flexible, pratique pour les moteurs croisés et l'analyse.

Caches (Redis/Memcached) : pas comme source de vérité ; répliques/snapshots, lancements chauds.

PITR : Journaux continus (WAL/redo) sur le stockage offsite, fenêtre de récupération ≥ 7-30 jours.

6) Cohérence et modèles de négociation

Saga + Outbox : les transactions commerciales comme une chaîne d'étapes, la publication des événements atomiquement avec une entrée dans la base de données.

Exactly-once « au sens » : idempotence des opérations, contrôle des versions du bilan (verrouillage optimiste).

Consistency eventual dans les flots non flous (leader, analyste) ; strong pour l'argent.

7) Composants et leur faussaire

API/backend

Conteneurs Statles, Scale automatique, bleu-vert/canary ; configi via le stockage (avec versioning).

Files d'attente/strim

Clusters de quorum (N = 3/5), réplique croisée AZ ; politiques de répétition et dlt-queue.

Porte-monnaie OBD

Primari dans la région A, réplique synchro dans A (une autre AZ), asynchrone dans la région B ; La promotion automatique dans split-brain est interdite - seulement manuelle/script avec check-list.

Fichiers/artefacts KUS

Stockage objet avec versioning, réplique croisée/CRR, clés dans KMS.

WebSocket/Real-time

Sharding par clé (table/game/market), sticky-routing ; pour le feelover, resubscribe avec un jeton rejoin.

8) Paiements et fournisseurs de jeux : nombreuses sources de vérité

Failover PSP : minimum 2 fournisseurs par méthode (carte, portefeuille, crypto).

Pourcentage de routage par SLA/coût/bannières BIN ; désactivation de la PSP dégradée par un automate.

Fournisseurs de jeux : canaux de sauvegarde/ASN allow-list, clés individuelles par région, isolation des temporisations.

9) Webhooks et saucisses : Accueil et reproduction durables

Modèle Inbox : nous acceptons le webhook → vérifions la signature/NMAS → écrivons dans immutable-inbox → traitons le worker idempotent.

Retraits des fournisseurs : backoff + dedup par 'event _ id'/' signature'.

Dans DR : repliement à partir d'une boîte avec contrôle d'ordre (txn → settlement).

10) Backaps : Stratégie 3-2-1 et vérification du rétablissement

3 copies/2 médias/1 offsite (et 1 hors ligne/WORM pour les journaux critiques).

Horaires : snapshots quotidiens + journaux permanents ; test-restore hebdomadaire sur le stand « sombre ».

Catalogues de restauration : « Comment lever votre portefeuille au moment du t- Δ ».

11) Plan DR : rôles, scénarios, communications

Роли: Incident Commander, Comms, DB Lead, App Lead, Payments/Game PM, SRE Oncall.

Chaînes : war-room, status page, modèles de messages sapport/partenaires/affiliés.

Scripts (minimum) :

• Perte AZ, perte de région, indisponibilité PSP, chute d'un cluster OBD, dégradation du fournisseur de jeux, fuite de clés, masse 5xx.

12) Exemple de matrice de scénarios DR

13) Runbook 'et automatisation

Bouton « DR-cutover » : séquence d'étapes avec validation (freeze writes → promote → warm caches → traffic ramp).

Scripts de vérification de l'intégrité : rapprochement des montants par ledger/portefeuille, cohérence des bilans.

Feature-flags : Rapide disable reports/export/dashboards lourds en cas d'accident.

14) Observabilité pour le faucher

Métriques SLO comme déclencheurs : login, dépôt, parier, lancer le jeu.

Технические: replication-lag, WAL-shipping, queue-lag, 5xx, p95, SYN backlog, WebSocket disconnects.

Scénarios synthétiques d'autres régions : login/dépôt/pari chaque minute.

Traces de fin de ligne, étiquettes 'region', 'psp', 'game _ provider'.

15) Exercice Chaos/DR

GameDay trimestriel : arrêt AZ, dégradation PSP, « perte » du nœud OBD, arrêt de la file d'attente.

Rétrospective : temps de décision, alertes manquantes, bruit, goulets d'étranglement.

Ajustement du RTO/RPO et de l'automatisation en fonction des faits plutôt que des « sensations ».

16) Sécurité et conformité

Clés/secrets dans KMS/HSM (cross-regional), rotation et dual-control.

WORM/immutabilité pour les journaux d'audit et de transaction.

DPA/contrats avec PSP/fournisseurs pour les obligations SLA/DR et les points de contact 24 × 7.

17) Exemple de politique minimale de faussaire (pseudo-code)

on Incident(type="REGION_DOWN"):
freeze_non_critical_writes()
promote_db(region=B)
verify_ledger_consistency()
warm_caches(region=B)
route_traffic(region=B, ramp=10%)
for step in [25%, 50%, 100%]:
if SLO_green(): ramp(step) else rollback()
announce_statuspage()

18) Chèque de disponibilité (prod-ready)

• Défini par RTO/RPO pour chaque flou ; accepté par les entreprises.
• Multi-AZ minimum ; Multi-région pour portefeuille, login et paiements.
• Ledger + idempotence (keys) + outbox/inbox ; reconciliation programmée.
• Réplication OBD : sync localement, async dans DR ; PITR est activé, restore vérifié.
• Deux PSP par méthode, une politique d'itinérance et des clés de test ; les fournisseurs de jeux sont des alternatives.
• DNS/GSLB/Anycast, chèques santé et synthétiques, TTL faible.
• Runbook 'et « DR-cutover bouton », feature-flags pour la dégradation.
• SLO/alertes/tracing ; le panneau « Statut DR ».
• Exercice de DR trimestriel + rétro ; contacts mis à jour 24 × 7.

---

Résumé

Une plate-forme iGaming fiable est construite autour d'un circuit monétaire : un journal de câblage avec idempotence, un faussaire prévisible, une réplication vérifiable et des exercices DR réguliers. Divisez le système en cellules et en régions, automatisez le cutover, gardez deux fournisseurs de jeux PSP et de jeux de rechange, surveillez le SLO et l'intégrité du ledger - et même un accident majeur deviendra un événement gérable sans perte de confiance et d'argent.