TL;DR: Routing and stateless compute are the easy half. The design is decided by the data layer, and common options include: partition users by region so writes are local, accept eventual consistency with conflict resolution, or keep a single write region and serve reads locally. Pick one explicitly, because pretending you can have global strong consistency with low latency is where candidates lose this round.
How to approach it
Ask what "active-active" is meant to buy: lower latency for distributed users, or survival of a region loss. They lead to different designs. Then get to the data question quickly, because everything else is downstream of it.
A strong answer
The easy half: DNS or anycast routes users to the nearest healthy region, each region runs a full stateless stack, health checks withdraw a region that fails. Deployments roll region by region so a bad release cannot take both at once. This part is well understood and nobody is testing it.
Choose write authority and consistency per data invariant:
Partition by user. Each user's data has a home region and their writes always go there. Cross-region reads are possible but writes are local, so same-key writes can be serialized at that owner. Promotion and rebalancing must fence the old owner and transfer an agreed committed position; local write conflicts still need concurrency control. The costs: routing must be by user rather than by geography, so a travelling user may get a distant region; and rebalancing users between regions is real work you will eventually need.
Multi-primary with conflict resolution. Both regions accept writes for the same data and reconcile asynchronously. You need a conflict strategy: last-write-wins (simple, silently loses data), CRDTs (correct, only for data shaped to fit them), or application-level merge. Honest position: this is right for a small set of data types such as counters, carts and presence, and wrong for anything where a lost write is unacceptable. Protect monetary invariants with an authoritative ledger and reservation rules. Derived balances and settlement projections can be asynchronous when the product contract permits it.
Single write region, global reads. Writes go to one region, replicas serve reads everywhere. Simple and correct, and it is not really active-active for writes. Read latency is local, write latency is cross-region for distant users, and failover means promoting a replica with whatever replication lag was outstanding. For many systems this is the right answer and admitting it scores better than an elaborate design that does not work.
Global consensus is another option. A distributed SQL system can provide strong consistency across regions, with placement and quorum choices affecting latency and availability. It does not provide local-only write latency everywhere.
The arithmetic that constrains everything: a cross-region round trip is tens to low hundreds of milliseconds. Synchronous replication puts that inside every write, so a strongly consistent multi-region write path costs at least one round trip per commit. Normal-operation coordination latency is distinct from CAP’s consistency-versus-availability tradeoff during a partition.
Then the operational half, which candidates skip and interviewers care about. Each region must be sized to carry the full load if the other fails, so you are running roughly 200 percent of capacity, or you accept degradation and say so. Failover must be rehearsed, because an untested failover has an unknown success probability. And you need a fencing mechanism for split brain: a partition where both regions believe they are primary is worse than an outage, so promotion needs durable authority and enforced fencing, whether initiated automatically or by a human, never an automatic timer on each side independently.
What interviewers probe next
"What is your RPO on failover?" Replication lag at the moment of failure. Which means lag is a monitored, alerted, first-class signal rather than a dashboard curiosity.
"How do you test it?" Scheduled region evacuation with real traffic, in business hours. Anything less is a document.
"Where does the session live?" If sessions are sticky to a region, a region loss logs everyone out. Either replicate them, accept it, or make them stateless tokens.
Common mistakes
Designing the routing and stopping. The data layer is the question.
Claiming strong consistency and low latency across regions, which the physics does not permit.
Forgetting capacity headroom, so the surviving region falls over the moment it inherits the load.
References