Qu'est-ce que la réplication de base de données multi-région ?

La réplication multi-région est une topologie de base de données qui copie les données entre régions pour réduire la latence de lecture et résister aux pannes. L’ennemi, c’est la physique : un aller-retour à travers un océan coûte des dizaines de millisecondes avant que la base ne fasse le moindre travail, et les patterns de requêtes bavards le paient à répétition. La réplication rapproche les données des utilisateurs — et soulève aussitôt les questions qui définissent le sujet : qui accepte les écritures, jusqu’à quel point les lectures peuvent être périmées, et si vous en avez déjà besoin.

Points clés

Mesurez avant de répliquer

Avant toute décision de topologie, obtenez le chiffre dont elle dépend — ce que coûte réellement un aller-retour à vos utilisateurs, région par région :

// JavaScript / Node.js — Back4app JS SDK
// Latency probe: measure what users in this region actually feel
const probe = new Parse.Query('HealthCheck');
probe.limit(1);

const started = Date.now();
await probe.first();               // one lightweight read
const readMs = Date.now() - started;

const sample = new Parse.Object('LatencySample');
sample.set('clientRegion', 'eu');  // where this client runs
sample.set('readMs', readMs);
await sample.save();               // writes always travel to the primary

console.log(`read: ${readMs} ms — reads can be served locally,`);
console.log('writes pay the distance to the primary region');

// Flutter / Dart — Back4app Flutter SDK
// Latency probe: measure what users in this region actually feel
final probe = QueryBuilder<ParseObject>(ParseObject('HealthCheck'))
  ..setLimit(1);

final started = DateTime.now();
await probe.query();               // one lightweight read
final readMs = DateTime.now().difference(started).inMilliseconds;

final sample = ParseObject('LatencySample')
  ..set('clientRegion', 'eu')      // where this client runs
  ..set('readMs', readMs);
await sample.save();               // writes always travel to the primary

print('read: $readMs ms — reads can be served locally,');
print('writes pay the distance to the primary region');

// iOS / Swift — Back4app Swift SDK
// Latency probe: measure what users in this region actually feel
let probe = HealthCheck.query().limit(1)

let started = Date()
probe.first { result in            // one lightweight read
  let readMs = Int(Date().timeIntervalSince(started) * 1000)

  var sample = LatencySample()
  sample.clientRegion = "eu"       // where this client runs
  sample.readMs = readMs
  sample.save { _ in               // writes always travel to the primary
    print("read: \(readMs) ms — reads can be served locally,")
    print("writes pay the distance to the primary region")
  }
}

// Android / Kotlin — Back4app Android SDK
// Latency probe: measure what users in this region actually feel
val probe = ParseQuery.getQuery<ParseObject>("HealthCheck")
probe.limit = 1

val started = System.currentTimeMillis()
probe.getFirstInBackground { _, e ->      // one lightweight read
    val readMs = System.currentTimeMillis() - started

    val sample = ParseObject("LatencySample")
    sample.put("clientRegion", "eu")      // where this client runs
    sample.put("readMs", readMs)
    sample.saveInBackground {             // writes travel to the primary
        println("read: $readMs ms — reads can be served locally,")
        println("writes pay the distance to the primary region")
    }
}

Quand les chiffres justifient bel et bien des répliques, la machinerie est standard — ici avec la réplication logique de PostgreSQL, où le lag est une donnée à part entière, interrogeable :

-- Sur le primaire (région A) : publier les changements
CREATE PUBLICATION app_pub FOR ALL TABLES;

-- Sur la réplique (région B) : s'abonner et recevoir le flux
CREATE SUBSCRIPTION app_sub
  CONNECTION 'host=primary.internal dbname=app'
  PUBLICATION app_pub;

-- Le chiffre qui définit votre fenêtre de données périmées :
SELECT application_name,
       now() - reply_time AS approx_lag
FROM pg_stat_replication;

Un primaire, plusieurs régions — le flux et le lag

C’est la topologie à tout faire — replica sets dans les bases documentaires, répliques en streaming dans les bases relationnelles — et ses deux coûts sont visibles sur le diagramme. Latence des écritures : chaque écriture voyage jusqu’à la région du primaire, si bien que les utilisateurs éloignés paient la traversée de l’océan précisément sur leurs actions de modification. Lag : les flux inter-régions sont asynchrones — une réplication synchrone ajouterait l’aller-retour complet à chaque commit —, donc les répliques accusent un retard de quelques millisecondes à quelques secondes, et les lectures peuvent être périmées d’autant. Le piège classique est le read-your-own-writes : enregistrer, rafraîchir depuis la réplique locale, ne rien voir. Les remèdes relèvent de la politique de routage, pas de la magie — envoyez au primaire les lectures qui suivent l’écriture d’un utilisateur, ou épinglez sa session jusqu’à ce que la réplique ait rattrapé son retard.

L’étape suivante — plusieurs primaires d’écriture — localise aussi les écritures, mais achète la marchandise la plus coûteuse du théorème CAP : des écritures concurrentes et conflictuelles dans différentes régions doivent être détectées et résolues. Les charges de travail sans conflit (données par utilisateur, flux en ajout seul) s’en accommodent bien ; l’état mutable partagé, très mal.

Mono-région vs. répliques de lecture vs. multi-primaire

La lecture honnête du tableau : chaque colonne vers la droite échange de la simplicité contre de la localité. La plupart des produits devraient s’en tenir à la colonne la plus à gauche qui satisfait leurs objectifs de latence et de disponibilité — et beaucoup découvrent qu’un CDN pour les assets associé à une région de base de données bien choisie les atteint déjà, puisque le poids statique domine généralement le temps de chargement perçu.

Cas d’usage courants

• Produits mondiaux à forte lecture. Catalogues, contenus, dashboards — un trafic dominé par la consultation, où des répliques régionales transforment des océans en quelques millisecondes.
• Bases d’utilisateurs régionales avec une traîne mondiale. Le primaire dans la région du marché principal, des répliques là où vit la traîne.
• Reprise après sinistre et basculement. Une copie à jour dans une autre région comme stratégie de disponibilité — précieuse même quand la latence n’a jamais justifié de répliques.
• Résidence des données. Conserver les données de certains tenants dans certaines juridictions — un partitionnement par tenant selon la région, cousin réglementaire de la réplication.
• Assurance de portabilité. Répliquer sur des moteurs open-source garde la topologie entre vos mains — une couverture discrète contre le vendor lock-in que les bases de données mondiales propriétaires n’offrent pas.

Devriez-vous passer au multi-région ? Matrice de décision

L’ordre du diagnostic compte : profilez les requêtes et ajoutez des index d’abord, regroupez les patterns de requêtes bavards ensuite, placez les assets statiques sur un CDN en troisième, choisissez bien votre région unique en quatrième — et répliquez en cinquième, quand la latence restante est véritablement géographique. Les équipes qui sautent directement à la cinquième étape héritent des problèmes des systèmes distribués alors que leur vrai goulot d’étranglement était une requête non indexée.

Limites et trade-offs

• Le lag est structurel. Les flux asynchrones sont en retard par conception ; chaque lecture sur une réplique porte une fenêtre de données périmées que votre produit doit tolérer ou contourner par le routage.
• Les écritures traversent toujours l’océan. Les topologies à primaire unique ne localisent que les lectures — le paiement, la publication, la réservation paient toujours la distance.
• Le basculement est une procédure, pas une promesse. Promotion, bascule du trafic et risque de perdre des écritures non répliquées (encore le RPO) — exercez-le avant d’y croire.
• Le multi-primaire importe des conflits. Des écritures concurrentes sur le même enregistrement dans deux régions doivent fusionner d’une manière ou d’une autre ; « last write wins » est une politique de perte de données déguisée en valeur par défaut.
• Le coût croît avec le nombre de copies. Stockage, sortie de données (egress) entre régions et attention d’ingénierie pour un système distribué de plus — à chiffrer honnêtement, région par région.
• La réplication n’est pas une sauvegarde. Chaque réplique copie fidèlement vos erreurs en quelques secondes ; la restauration à un instant donné existe justement pour la catégorie de pannes que la réplication propage.

Multi-région et latence sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. La mécanique de réplication vit sous votre code : la base de données gérée tourne sur une infrastructure répliquée dont le basculement est pris en charge par la plateforme, et le choix de la région à la création de l’application place le primaire là où sont vos utilisateurs — la décision de latence au plus fort effet de levier, celle que cet article recommande de prendre en premier. Comme le stack est open-source de bout en bout, la topologie reste portable : les mêmes Parse Server et moteurs de base de données tournent partout où vous pourriez un jour avoir besoin d’une région absente du menu de la plateforme.