Architecture multi-régions

Tourner dans plusieurs régions protège d'une panne régionale et rapproche les données des utilisateurs. La difficulté, ce sont les données : la réplication synchrone ajoute la latence inter-régions aux écritures, l'asynchrone risque de perdre les écritures récentes.

Où on le retrouve dans les vrais systèmes

  • Load balancer global

    Une seule IP anycast attire les utilisateurs vers le point de présence le plus proche, puis le trafic emprunte la dorsale du fournisseur jusqu'à la meilleure région. Contrairement au basculement DNS, changer de région n'attend pas l'expiration des caches.

    En production : AWS Global Accelerator, Google Cloud global external LB, Azure Front Door, Cloudflare Load Balancing

  • SQL distribué

    Chaque écriture est validée par un protocole de consensus (Raft ou Paxos) : elle n'est jamais perdue et chaque lecture est à jour, même entre régions. Le prix est la latence : une écriture doit atteindre une majorité de réplicas, et entre régions cela représente des dizaines de millisecondes.

    En production : Google Cloud Spanner, CockroachDB, YugabyteDB, TiDB, Amazon Aurora DSQL

  • Liaison inter-régions

    Transporte la réplication et le trafic de services entre régions. Une réplication synchrone ajoute tout l'aller-retour à chaque écriture ; une réplication asynchrone risque de perdre les dernières secondes au basculement.

    En production : AWS Transit Gateway, VPC peering, Azure Global VNet Peering

Regarde-le casser, puis répare-le

Construis une architecture, envoie-lui une journée de trafic et de pannes, et comprends pourquoi elle tient ou cède. Gratuit pour commencer.

Ouvrir le parcours Ouvrir le bac à sable