Architecture de référence : multi-région / globale

Lorsque les utilisateurs sont géographiquement répartis ou qu'une résilience à un sinistre régional est requise, les données se répartissent sur plusieurs régions. Cet arbre parcourt pas à pas la localité des lectures (un réplica de lecture dans chaque région), la topologie d'écriture (single-leader vs multi-leader vs quorum), la résidence des données/la conformité (RGPD), la résolution des conflits et les compromis entre RPO/RTO et latence. La vérité de base : en raison des lois de la physique, faible latence, cohérence forte et écritures multi-régions ne peuvent pas toutes être pleinement obtenues en même temps ; un compromis délibéré est obligatoire.

Pourquoi passer en multi-région : localité des lectures, écritures/résilience ou conformité ?

Une architecture multi-région est coûteuse et complexe ; clarifiez la motivation. Voulez-vous une faible latence de lecture pour les utilisateurs éloignés, des écritures inter-régions/une résilience aux sinistres, ou la vraie exigence est-elle que les données restent dans un pays précis (résidence légale) ?

• Lectures rapides pour les utilisateurs éloignés ; les écritures peuvent rester dans une région
• Écritures inter-régions / résilience à la perte d'une région requises
• Les données doivent légalement rester dans un pays/une région précis(e)

Quelle topologie d'écriture : single-leader, multi-leader ou quorum ?

Pour les écritures inter-régions, la décision clé est le modèle de leadership. Toutes les écritures vont-elles vers une seule région (simple, cohérent, mais écritures distantes lentes), chaque région peut-elle écrire (faible latence d'écriture mais conflits), ou une écriture est-elle acceptée avec l'acquittement d'une majorité de régions (quorum : cohérent mais avec une latence supplémentaire) ?

• Une région écrit, les autres lisent (simple et cohérent)
• Chaque région peut écrire localement (faible latence d'écriture)
• Écriture avec acquittement majoritaire ; la cohérence prime

Recommandation : un réplica de lecture par région (localité des lectures)

Les écritures restent dans une seule région primaire tandis que vous placez dans chaque région d'utilisateurs un réplica de lecture alimenté par celle-ci. Les utilisateurs lisent depuis le réplica le plus proche et la latence de lecture baisse ; comme les écritures vont toujours vers un centre unique, le modèle de cohérence reste simple.

Recommandation : écritures single-leader

Toutes les écritures vont vers une seule région leader ; les autres régions sont des réplicas de lecture alimentés de façon asynchrone par ce leader. C'est le modèle le plus simple et le plus fortement cohérent ; il n'y a pas de conflits car il n'existe qu'un seul point d'écriture. Le prix est une latence d'écriture élevée depuis les régions distantes.

Recommandation : écritures multi-leader + résolution des conflits

Comme chaque région peut écrire localement, la latence d'écriture est faible et, même si une région est coupée, les autres continuent d'écrire. Le prix est lourd : deux régions peuvent mettre à jour différemment le même enregistrement, et vous devez concevoir la résolution des conflits.

Recommandation : écritures par quorum (acquittement majoritaire)

Une écriture est acceptée lorsqu'une majorité (quorum) de régions/réplicas l'acquitte ; lorsque les lectures vont aussi vers une majorité, la valeur la plus récente est garantie. C'est résilient à la perte d'une région et fortement cohérent ; le prix est la latence de chaque écriture devant atteindre une majorité.

Recommandation : résidence des données / conformité (RGPD)

Certaines données (personnelles, de santé, financières) doivent légalement rester à l'intérieur des frontières d'un pays/d'une région précis(e) (par ex. RGPD). Dans ce cas, vous concevez l'architecture non pas selon le principe « copier partout » mais de sorte que les données soient ancrées géographiquement.