failover

Anycast turns BGP convergence into your failover mechanism. Sessions stick to the site they landed on, monitoring must go per-site, and a route you cannot withdraw cleanly is worse than DNS.

Database redundancy still needs reconnecting clients. Distinguish the deployment type, then measure how promotion and DNS changes affect application requests.

DNS failover is a blunt instrument with three delays stacked on top of each other: detection, propagation and client caching. Knowing their sizes tells you when DNS is the right layer at all.

Split-brain writes are a fencing failure first and a data problem second. Freeze writes, read the divergence boundary from replication positions, and let the payment ledger arbitrate reality.

The design round where the honest answer is mostly about data. Stateless traffic across regions is straightforward; the database is where active-active is either solved or pretended.

Every candidate says replication and failover. The scoring answer names the replication mode, states the resulting data loss window, and explains how the cluster avoids two primaries.

The Google-style NALSD round in miniature. The boxes are easy; what is being scored is whether the numbers fall out of Little's law before you draw them.

DNS time-to-live is a suggestion and nineteen minutes is what believing it costs. The mechanism you choose decides your failover time, and the health check you choose decides whether it fires at all.

A model provider is a single dependency with a shared failure domain across every customer they have. Treating it like a database you cannot fail over from is how a product goes down for four hours.