Design a globally distributed, multi-region active-active system. Walk me through the hard parts.
What they are really testing: Whether you grasp the genuinely hard problems of global systems, data consistency, conflict resolution, failover, and whether you can reason about CAP trade-offs at scale. They expect you to lead with the hard parts, not the happy path.
A real interview question
Design a globally distributed, multi-region active-active system. Walk me through the hard parts.
What most people say
drag me
“I would deploy the app to multiple regions and put a global load balancer in front.”
That is the easy 10%. It ignores the entire hard problem, replicating and reconciling state across regions, conflict resolution, and the CAP trade-off. Glossing the data layer is the tell that someone has not run global systems.
The follow-ups they ask next
Two regions accept a conflicting write to the same record during a partition. What happens?
It depends on the model you chose: home-region partitioning prevents it; multi-master needs a deterministic resolution (CRDT merge, version vectors, or business-rule merge). "Last write wins" silently loses data, a strong candidate flags that as usually unacceptable.
How do you know your failover actually works?
Game days / chaos engineering: regularly and deliberately fail a region in production-like conditions and measure RTO/RPO. Untested failover is a liability; the discipline of rehearsing it is the principal-level signal.
What the interviewer is listening for
- Leads with data/consistency as the hard part
- Chooses consistency per data class
- Has a real conflict-resolution strategy
- Rehearses failover (game days)
- States the CAP trade-off explicitly
What sinks the answer
- Treats it as "deploy to N regions + global LB"
- Hand-waves the data layer
- Silent last-write-wins on critical data
- Assumes failover works without testing
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“First, why active-active, [latency / DR / residency]? Compute per region is easy; [data is the hard part]. I’d set consistency per data class, [strong for payments, eventual for profile], resolve writes via [home-region partitioning or CRDTs, never silent LWW], route users [to nearest healthy region with tested failover], and state the [CAP trade-off] explicitly.”
Keep going with architecture & design
Junior
How does putting a load balancer in front of your app improve availability, and what does it NOT solve?
Junior
What is autoscaling, and how does it decide when to add or remove instances?
Senior
Design a highly available web application on AWS. Walk me through the architecture and your trade-offs.
Senior
Design a disaster recovery strategy for a revenue-critical workload on AWS. How do you pick between backup-and-restore, pilot light, warm standby, and active-active?
Senior
Design a scalable async processing pipeline for spiky, long-running work (think video transcoding or report generation). Walk me through the queue-based architecture and its failure modes.
Senior
You own a system of many services and an incident took too long to diagnose. Design an observability strategy across the whole estate.
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free