Problem statement
Design the platform layer that decides which regional deployment serves each incoming request and orchestrates failover when a region degrades. The company runs its stack in several regions; normally each user is served from the nearest healthy one, but when a region loses capacity, database primary, or network reachability, traffic must shift away from it quickly and shift back cleanly when it recovers.
Operating context. The router sits at the very front of the request path, so any latency or unavailability it adds hits everything. Health must be judged from real signals (synthetic probes, error rates, capacity), not a single ping. Failover has to be fast but must not flap on a transient blip, and it must avoid split-brain where two regions both believe they are primary for stateful writes. Some sessions need affinity to the region that holds their in-progress state. Both automatic failover and operator-initiated (planned maintenance) failover are required.
Out of scope. The application services running inside each region, cross-region data replication mechanics (assume a replication story exists with a known RPO), TLS termination details, and DDoS scrubbing. Assume other teams own those.
What to produce. A high-level architecture covering: the traffic-steering mechanism (DNS/anycast/edge) and its propagation trade-offs, how region health is aggregated into a routing decision, how automatic and planned failover are triggered and how fast (RTO), how flapping is damped, how split-brain for stateful writes is prevented, how session affinity is honored across a failover, and how the control plane stays available and consistent independent of any one region. Sketch the components and flow; we will probe specifics in checkpoints.
Requirements
The requirements come with Premium
Premium