Partage et réplication de bases de données

(Section : Technologie et infrastructure)

Résumé succinct

Pour les plates-formes iGaming, l'augmentation du trafic (paris, dépôts, webhooks PSP, événements de jeux) et les exigences de disponibilité (≈99. 9–99. 99 %) sont rapidement enfoncés dans la limite d'un OBD. La réplication permet une mise à l'échelle horizontale de la lecture et une tolérance aux pannes ; sharding - mise à l'échelle horizontale de l'enregistrement et des données. La clé est les compromis conscients de PACELC (après échec : CA/P, sinon : Laticy vs Consistency), SLO clair et la discipline des schémas/clés.

Termes et modèles

Réplication : Copie des données entre les sites.

Leader-Follower (Primary-Replica) : un enregistrement → beaucoup de lectures.
Multi-Leader (Active-Active) : entrées dans plusieurs régions, conflits/merge.
Consensus-replication (Raft/Paxos, NewSQL) : enregistrements de quorum (Cassandra/Scylla - AP-quorum, CockroachDB/Yugabyte - CP-quorum).
Sync/Semi-sync/Async : équilibre de retard vs RPO.
Le sharding est une partition horizontale des tables/clés en chardes.

Hash-sharding (uniformité, gammes plus complexes).
Range-sharding (gammes de clés, risque d'extrémités « chaudes »).
Consistent hashing (addition douce/réduction des nodules).
Géolocalisation (par région/juridiction).
Partage fonctionnel (par domaine : paiements/tarifs/CRM).

Quand et quoi choisir dans iGaming

Seule la réplication (pas de partage) - lorsque le problème principal est la lecture : flux d'événements, rapports, répertoires publics. Les enregistrements sont placés dans le même leader, les lectures dans les répliques.
Sharding - quand un goulot d'étranglement d'écriture/stockage : flux de paris, transactions de bilan, événements déclencheurs.

Multi-region:

Latence aux joueurs/PSP → lectures locales des répliques.
Réglementation (localisation des données) → géolocalisation.
DR interrégional → réplique asynchrone + plan de commutation.

Propriétés PACELC et garantie

CAP : dans le réseau-split, nous choisissons C (consistance) ou A (disponibilité).
PACELC : En l'absence de défaillances, nous sélectionnons entre Latinity (L) et Consistency (C).
Trajets monétaires (bilan, débits) : habituellement orientés C (CP/strict serializable ou Serializable + idempotence d'affaires).
Sous-systèmes moins critiques (journal de clics, catalogues) : orientés L (AP/EC, eventual).

Réplication : Pratiques

Leader–Follower

Les entrées → le leader, les lectures → les répliques (read scaling).
Read-after-write : pour les opérations personnalisées, lisez à partir du leader ou attendez un ligh (vérifiez 'last _ committed _ lsn'/' wait _ for _ replay _ lag').
Semi-sync sur les voies critiques (réduction du RPO au prix de la latence).
Failover : automatique (patroni/coordinateur raft) + fencing (pour qu'il n'y ait pas de double leader).

Multi-Leader

Convient pour les domaines divisés et les conflits faibles (par exemple, le contenu/les paramètres), mais pas pour le compte unique du joueur sans mesures spéciales.
Politiques Merge : last-write-wins, CRDT, règles de consolidation de domaine.

Consensus/OBD de quorum

Écriture avec quorum (par exemple, 'WRITE QUORUM'), lecture avec quorum ('READ QUORUM') → consistance forte/personnalisable.
Tenez compte de la latence inter-AZ/régions et du coût du quorum.

Sharding : stratégies et choix de la clé

Comment choisir une clé

Répartition stable par player_id/ account_id/ bet_id.
Évitez les clés monotones (auto-incrément) dans le range-charding - queue « chaude ».
Pour les paiements, souvent 'player _ id' ou 'account _ id' ; pour les logs - 'event _ time' + bucketing ; pour le contenu : 'tenant _ id'.

Stratégies

Hash-sharding par player_id : équilibre sur le flux de paris/soldes.
Range-sharding dans le temps pour les analyses/archives.
Geo-sharding : Joueurs EU → EU-shard (respect des lois locales).
Hybride : hash à l'intérieur de la région + geo par juridiction.

Lutte contre les clés « chaudes »

Key-salting (ajouter sel/bucket à la clé).
Write-throttling par essence, file d'attente des commandes (serial executor).
Matérialiser les « agrégats » (équilibre) dans un store séparé avec une file d'attente de séquence.

Opérations de cross-chard

Transfert d'argent/compensation : éviter les 2PC sur les voies chaudes.
Modèle de saga : décomposé en transactions locales + actions compensatoires, idempotence rigide et outbox.
2RS/protocoles de commit : acceptables par points (batchs back-office), mais coûteux en latence et tolérance aux pannes.
Projections : représentations de lecture (read models) pour écrans inter-domaines, mises à jour à partir d'un stream.

Schémas, indices et évolution

Versioner le schéma : migration avec back-compat, feature-flags sur le code.
Index des clés de chardonnage et des requêtes fréquentes ; éviter le cross-shard join (faire le pré-join/dénormaliser).
Pour le stockage JSON/quai - Validez les schémas (JSON-Schema/Protobuf) et TTL pour les collections « bruyantes ».

Mise à l'échelle et resharding en ligne

Planifiez le nombre N≫tekushcheye de chars virtuels (slots) → de rebalance flexible.
Consistent hashing ou « noeuds virtuels » pour ajouter des nœuds en douceur.

Online-resharding :

double enregistrement (vieux + nouveau shard), validation de consistance ;
copies de fond des cuves (logical dump/table move/streaming clone) ;
commutation par « marqueur » + fenêtre d'observation, puis retrait du double enregistrement.
Délocaliser un leader sans temps d'arrêt : basculer les rôles, drainer les connecteurs.

SLO, observabilité et alerting

Écriture/lecture SLO : p99 ≤ X ms sur tables chaudes, réplique lag valide ≤ Y secondes, disponibilité ≥ Z.
Métriques : TPS, p95/p99, replication lag, conflit (multi-leader), retry rate, deadlocks, lock wait, cache hit ratio, IOPS/latency disque.
Trace : 'trace _ id'dans les requêtes OBD, associer au courtier/bus d'événements.
Enquêtes canaries et transactions synthétiques pour un détail précoce des dégradations.

Sécurité et conformité

Cryptage au repos et en transit (TLS), rotation des clés.
RBAC/ACL, segmentation par domaine/tenants, clusters distincts pour les paiements/CUS.
Localisation des données (EU/TR/LATAM) - combinez le géo-charding et les polices de rétentions.
Vérification : qui et ce qu'il a lu/les règles ; masquage du PII ; exportation d'audit.

Backups, PITR, DR

Backaps complets + incrémentiels, stockage offsite.
PITR (point-in-time recovery) pour les clusters leaders.

RPO/RTO:

Les domaines (balance/paiement) critiques - RPO≈0-30s (semi-sync ou fréquent WAL-chipping), RTO ≤ de la minute avec automatique failover.
Moins critique - RPO jusqu'à minutes/heures.
Exercice DR (game day) et runbook de commutation documenté.

Performance et tuning (bref)

Mémoire/cache : augmentez les tampons (buffers partagés/innodb buffer pool), surveillez cache-hit ≥ 95 %.
Journal/moteur : NVMe rapide, volume séparé sous WAL/redo.
Pool de connexions (PgBouncer/Hikari).
Planificateur/statistiques : Auto-analyse/Autopacuum (Postgres), compaction/tuning GC (moteurs LSM).
Quorum/réplique facteur : équilibre entre p99 et tolérance aux pannes.

Topologies types pour iGaming

1) Bilans et paiements (circuit CP)

Leader-Follower dans la région du joueur, semi-sync à une réplique proche.
Hash-sharding par 'account _ id'.
Lire « après l'écriture » à partir du leader ; projections dans Redis pour API-latency.
Outbox → bus d'événements pour les calculs/analyses.

2) Historique des paris/événements de jeu (journal orienté AP)

Range-sharding temporel ou hash par 'player _ id' dans la colonne/stockage LSM.
Répliques asynchrones pour reporting/OLAP.
La consistance eventuelle est acceptable, la bande passante est plus importante.

3) Profils/CRM (lecture multi-régions, localisation)

Géolocalisation par juridiction, répliques locales pour les lectures.
Enregistrements via le leader le plus proche ; région croisée - asynchrone + résolution de conflits uniquement pour les champs non critiques.

Exemples (conceptuels)

Postgres : partage déclaratif par 'player _ id'

sql
CREATE TABLE player_wallet (
player_id BIGINT NOT NULL,
balance_cents BIGINT NOT NULL,
updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
PRIMARY KEY (player_id)
) PARTITION BY HASH (player_id);

CREATE TABLE player_wallet_p0 PARTITION OF player_wallet FOR VALUES WITH (MODULUS 32, REMAINDER 0);
--... p1..p31

-- Репликация: публикация WAL на реплики, синхронность для «горячего» региона.
ALTER SYSTEM SET synchronous_standby_names = 'FIRST 1 (replica_eu1, replica_eu2)';

Enregistrement de quorum (pseudo)


WRITE CL=QUORUM  -- запись подтверждена большинством реплик
READ CL=LOCAL_QUORUM -- локальный кворум для низкой задержки

Saga au lieu de 2PC (simplifié)

1. Débiter le dépôt sur shard-A (idempotent).
2. Envoyer l'événement « retiré » → le service de paiement (shard-B).
3. Si l'étape 2 échoue, compenser l'étape 1 par l'événement « retour ».

Chèque de mise en œuvre

1. Définissez les domaines de données et SLO (p99, RPO/RTO, lag réplica).
2. Choisissez un modèle de réplication (leader/follower, quorum) et une stratégie de partage.
3. Fixer les clés de sharding et le schéma (immuables !).
4. Entrez la stratégie read-after-write et le routage des lectures.
5. Concevez le resharding en ligne (chardes virtuelles, double enregistrement).
6. Garantir l'idempotence et l'outbox pour les événements/commandes.
7. Personnalisez vos backups, PITR, DR et exercices réguliers.
8. Incluez l'observabilité : lag, quorum, clés chaudes, conflits.
9. Documenter runbook : failover, split-brain, dégradations.
10. Effectuer des tests de charge/chaos sous les pics de match.

Anti-modèles

Un shard géant « pour tout » et « ensuite nous le couperons ».
Join 'cross-chard sur le chemin chaud de la demande.
Pas de politique read-after-write (bugs flottants).
Migration des schémas « cassant » les clés de charding.
Multi-leader pour les comptes monétaires sans résolution rigoureuse des conflits.
Pas de PITR/DR - vous ne pouvez pas récupérer après une erreur logique.

Résultats

La réplication résout la lecture et la tolérance aux pannes, le sharding - l'écriture et le volume. L'architecture réussie d'iGaming est un SLO clair et des compromis PACELC, des clés de partage stables, un minimum de coordination cross-chard (saga au lieu de 2PC), une discipline de lecture-after-write, un resharding en ligne et des exercices DR réguliers. Cette approche s'adapte aux sommets des tournois, résiste aux restrictions réglementaires en matière de localisation des données et reste prévisible en service.