Comment fonctionne le failover et la sauvegarde dans iGaming

Pourquoi iGaming est une discipline spéciale DR/BCP

La plate-forme de casino est de l'argent en temps réel (portefeuille/ledger), des tours en direct (RNG/Live), des paiements, des affiliations et une stricte conformité. Tout « trou » dans l'accessibilité se transforme rapidement en risques financiers et juridiques. L'architecture s'articule donc autour d'une récupération prévisible : cibles connues, scénarios connus, procédures répétés.

Objectifs et termes de base

RTO (Recovery Time Objective) : temps de récupération du service.

Pour porte-monnaie/ledger : ≤ 60-300 secondes (feilover intrarégional), ≤ 15 min (DR interrégional).

RPO (Recovery Point Objective) : perte de données valide.

Pour le ledger : 0-5 secondes (réplication synchrone/quasi-synchrone), pour le rapport : ≤ 15 min.

SLA et Error Budget : formalisent les compromis entre la vitesse du changement et la stabilité.

Couches de tolérance aux pannes

1) Infrastructures : Multi-AZ/Multi-Région

Multi-AZ (minimum de 3 zones) : tous les services critiques sont répartis dans les zones, un faussaire automatique OBD/bus.

DR multi-région : « chaud » (Active-Active) ou « chaud » (Active-Passive) deuxième région avec isolement par juridiction (data residency).

La décision quand quel mode :

Active-Active : faible latence pour les joueurs dans les deux régions, ledger cross-region via la synchronisation des événements + strict « endroit de vérité » pour les calculs.
Active-Passive (warm) : plus facile et moins cher ; le passage tient des instances chaudes + répliques de BD, mais le trafic ne sert pas.

2) Réseau et périmètre

Double ingress/WAF, Anycast ou failover DNS avec contrôles de santé.

Passerelles egress séparées pour la caisse et les fournisseurs, listes des IP autorisées dans les deux régions.

3) Données et files d'attente

Bases de données relationnelles (Postgres) : Patroni/Managed HA, répliques synchrones dans AZ, réplique asynchrone dans la région DR (avec surveillance des lagunes). PITR avec snapshots toutes les N minutes + archives WAL.

OLAP (ClickHouse/BigQuery) : réplication/chardonnage ; la perte est admissible plus haut (RPO jusqu'à 15-30 min).

Cache (Redis) : cluster avec failover, mais pas source de vérité ; lors de la commutation - chauffage chaud.

Bus d'événements (Kafka/NATS) : clusters miroirs et/ou cross-cluster-mirroring, garantie « at-least-once », contrôle de l'idempotence sur les consommateurs.

4) Applications et domaines

Portefeuille/ledger : stateful-noyau avec consistance stricte, un « maître-ryter » par région ; avec le DR interrégional est la procédure « elected writer » avec verrouillage double enregistrement.

Pont de jeu/API : stateless, faussaire horizontal sur chèques santé ; idempotencyKey pour toutes les voies financières.

Bonus/notifications/ETL : permettent le traitement différé, redémarrent à partir des files d'attente.

Caisse (PSP/crypta) : stratégie multi-sites (minimum 2 rails par pays), commutation rapide des merchants/endpoints.

5) Strimes en direct

WebRTC/LL-HLS gateways avec des nœuds edge régionaux ; les itinéraires fallback sur LL-HLS lorsque WebRTC est dégradé.

Maintenir la logique des paris hors du lecteur pour que le redémarrage du strim n'affecte pas le calcul.

Modèles de failover

Actif-actif (bi-régional)

Avantages : RTO/RPO minimum, proximité avec les joueurs.

Inconvénients : complexité du ledger et conflits d'enregistrement, maillage coûteux.

Pratique : « un écrivain par domaine » + event sourcing pour reproduire des états dans une région voisine.

Actif-passe (chaud)

Avantages : équilibre prix/difficulté.

Inconvénients : RTO ci-dessus, vous avez besoin d'un plan de « promotion » de la région passive.

Pratique : automatisation + confirmation manuelle (principe à 4 yeux) lors du changement de portefeuille.

Intrarégional (Multi-AZ)

Autofilm OBD/cache/ingress.

Pas de changement DNS/Anycast, RTO secondes-minutes.

Sauvegarde (Backup) par classe de données

Classe	Exemples	Méthode	Fréquence	Stockage	Vérification
Transactions d'argent/ledger	Postgres (portefeuille, ledger)	Snapshots + archives WAL (PITR), réplique logique	5-15 min WAL, snapshot 1-4 h	Stockage d'objets avec Object Lock (WORM), région croisée	Récupération du DR hebdomadaire « à froid » + comparaison des montants de contrôle
Événements	Kafka topics	Tiered storage + mirror в DR	Sans arrêt	Stockage d'objets	Repliement des fenêtres de test
OLAP/rapport	ClickHouse/BigQuery	Snapshots/exportations de lots	1-6 h	Stockage d'objets	Lecture des échantillons de contrôle
Artefacts statiques	billets, logs, exportations	Versioné S3, Glacier	Chaque jour	WORM/versions	Restauration périodique
Secrets/clés	Métadonnées KMS/HSM	Exportation avec emballage, double contrôle	Comme prévu	Répliques HSM	Test de décryptage

Principes :

Le backup est crypté au repos et en transit, les clés sont dans KMS/HSM.
Mode immuable (WORM) pour les backups critiques (protection anti-effacement/ransomware).
Répertoire des backaps avec métadonnées (version du schéma, fenêtre WAL, montants de contrôle).
Le PITR est obligatoire pour le ledger.

Données et idempotence : comment éviter les « trous » dans le faussaire

IdempotencyKey sur les requêtes 'bet. place`, `payout. request`, `cashier. webhook`.

Ledger n'est qu'append-only : une nouvelle fois settle créera un enregistrement d'ajustement, pas un « écrasement ».

Les serrures transactionnelles/versioning d'équilibre protègent contre les courses lorsque vous changez de rôle d'auteur.

Déduplication des événements (consumer-side, hachage par champs clés).

Caisse, PSP et cryptage : le plan B est toujours inclus

Au moins deux fournisseurs par mode de paiement (carte/ARM), des comptes de merchant préétablis dans les deux régions.

Pour les steiblcoins, il y a deux réseaux (par exemple, TRC-20 et ERC-20) et deux fournisseurs d'accès.

Routeur de paiement : en cas d'échec de la PSP passe instantanément à la sauvegarde, tient un journal des causes.

Les flux KYT/AML sont dupliqués ; si le service externe n'est pas disponible - « mode dégradé » avec escalade manuelle.

Procédures opérationnelles (Runbooks)

Automatique

Chèque santé de la chaîne ingress → API → portefeuille → OBD → fournisseur.

L'auto-activation des fonctions « lourdes » (tournois/missions) lors de la dégradation du portefeuille.

Temporisation/rétraction avec pause exponentielle et deadlines strictes.

Manuel (avec confirmation)

Promotion de la région DR dans un atout : chèques par étapes, journalisation, modèles de com (sapport/partenaires/régulateur).

Rémunération/VOID par round : codes de cause, liens vers la vidéo, signature des responsables.

Décongélation des paiements avec double contrôle.

Exercices et contrôles de préparation

Game Day/Chaos Drill mensuel : arrêt AZ, dégradation OBD, chute du fournisseur.

Plein DR Rehearsal trimestriel : mettre la région DR « en pleine croissance », lancer des scénarios réels de taux/paiement.

Tests de restauration : restaurer le ledger à l'instant T, vérifier avec le contrôle P&L et les tranches de hachage.

Table-top avec complience : qui et qui notifie quels rapports sont formés (régulateur, PSP, affiliations).

Observabilité et signaux de faussaire

Métriques SLO : p95 portefeuille latin, part 'bet. réfected ', temps de settle round, SLA de paiement, lag de réplication OBD, lag Kafka-consumers.

Événements de basculement : alertes « role change », « replication lag> X », « object-lock violence ».

Dashboards DR : rôle actuel des nœuds, évaluation RPO (minutes WAL), état de la fenêtre PITR.

Sécurité et conformité

Isolation des données par juridiction (UE/UK/CA/...) : réplication dans les limites autorisées par les lois.

Journaux immuables (S3 Object Lock/WORM), rétentions selon les délais réglementaires.

Secrets : rotation des clés, partage des tâches (dual-control) pour les opérations de DR.

Audit-trail de tous les changements et restaurations.

Les anti-schémas qui cassent le DR

Un PSP/un réseau de steiblcoin par pays - pas de rail de secours.

OLTP et OLAP sur une seule base de données - la restauration bloque les opérations « en direct ».

Pas d'idempotencyKey - prises de débit/paiement sur les retraits.

Les backups sans test de restauration régulier sont les « backup de Schrödinger ».

L'absence de WORM/immutabilité est une vulnérabilité à la suppression initiée/malveillante.

Failover DNS sans TTL courts et endpoints chauffés.

Un seul écrivain dans deux régions à la fois - la division de l'état.

Chèque de préparation aux accidents

Architecture

Multi-AZ pour tous les services critiques, topologie documentée.
Région DR avec le rôle décrit (Active-Active/Passive) et le budget.

Données

Postgres : PITR, snapshots, lag-monitoring, tests de récupération réguliers.
Kafka/NATS : miroir/archive, plan de repli.
ClickHouse/OLAP : backaps de lot, récupération d'échantillons.
S3 : Object Lock (WORM), versions, cross-région.

Applications

Idempotency in money, append-only ledger, versioning balance.
Auto-feature-degrade en cas d'incident (tournois/missions off).
Contrôles canaris avant de changer de région.

Caisse et Crypta

Deux fournisseurs par méthode et deux réseaux pour les steables.
Routage et journal des causes des changements.
KYT/AML en mode degrade avec escalade.

Opérations

Runbooks avec RACI et téléphones de garde.
Les jours de chaos mensuels et les exercices trimestriels du DR complet.
Modèles de communication (sapport, partenaires, régulateur).

Observabilité

Dashboards RTO/RPO, alertes du rôle des OBD, lagunes, refus de paris/paiements.
Audit-journal des changements et des restaurations.

La fiabilité d'iGaming n'est pas un « bouton de feelover », mais un système d'habitudes : l'isolement géographique, les RTO/RPO prévisibles, l'argent idempotent, la caisse multiple, les backups immuables, les exercices réguliers et la communication transparente. Cette discipline permet de vivre des échecs sans perte dans le ledger, sans rounds « bouchés » et sans coups sur la confiance des joueurs et des régulateurs.