Basculement (failover)

Déplacer automatiquement le trafic ou le rôle de leader vers un secours quand le primaire tombe. Il faut détecter la panne de façon fiable, éviter deux leaders en même temps et accepter que quelques secondes de requêtes échouent.

Où on le retrouve dans les vrais systèmes

  • DNS

    Un DNS managé répond en environ une milliseconde grâce aux caches des résolveurs. Les politiques par latence, géolocalisation ou basculement envoient les utilisateurs vers la région la plus proche ou la plus saine ; un TTL bas accélère le basculement mais multiplie les requêtes.

    En production : Amazon Route 53, Cloudflare DNS, Azure DNS, Google Cloud DNS

  • Base de données relationnelle

    Le primaire traite toutes les écritures ; les réplicas en lecture ajoutent de la capacité mais ont un léger retard, un utilisateur peut donc ne pas voir sa propre écriture. Un standby multi-AZ prend le relais en une minute environ si le primaire tombe. Le sharding multiplie la capacité d'écriture, mais une mauvaise clé crée un shard chaud. Sans pool de connexions, beaucoup d'instances applicatives épuisent la limite de connexions.

    En production : PostgreSQL (Amazon RDS, Aurora), MySQL, Azure SQL Database, Cloud SQL, Citus, Vitess

  • Proxy de connexions à la base

    Place-le entre tes services et une base relationnelle. Les fonctions serverless et les grandes flottes ouvrent bien plus de connexions qu'une base ne peut en accepter ; le proxy les multiplexe et raccourcit aussi les basculements en gardant les connexions pendant que le standby prend le relais.

    En production : PgBouncer, Amazon RDS Proxy, ProxySQL, Odyssey, Supavisor

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