Failover

Automatically moving traffic or the leader role to a standby when the primary fails. It must detect the failure reliably, avoid two leaders at once and accept that a few seconds of requests fail.

Where it shows up in real systems

  • DNS

    Managed DNS answers in about a millisecond thanks to resolver caches. Latency-based, geolocation and failover policies send users to the closest or healthiest region; a low TTL makes failover faster but increases queries.

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

  • Relational database

    The primary handles every write; read replicas add read capacity but lag slightly behind, so a user may not see their own write. A Multi-AZ standby takes over in about a minute if the primary fails. Sharding multiplies write capacity, but a bad shard key creates a hot shard. Without connection pooling, many app instances exhaust the connection limit.

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

  • Database connection proxy

    Place it between your services and a relational database. Serverless functions and large fleets open far more connections than a database can hold; the proxy multiplexes them and also shortens failovers by holding connections while the standby takes over.

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

See it break, then fix it

Build an architecture, send it a day of traffic and outages, and learn why it holds or fails. Free to start.

Open the learning path Open the sandbox