This question is testing whether you know that the database is the ceiling, and whether you can pick an architecture whose consistency story actually holds. A strong answer starts from the physics, names the two real architectures, and shows what each one does to your write path before talking about traffic routing.
The mental model: compute is portable, state is not. Latency is set by fiber physics: information travels at roughly two-thirds of vacuum speed in glass, so RTT is ~10 ms per 1,000 km, typically 1.5-2x the theoretical floor in practice — us-east-1 to eu-west-1 is ~75-85 ms typical, us-east-1 to ap-southeast-1 ~220-250 ms. A synchronous request crossing the Atlantic in both directions pays ~150-170 ms of network time before your code runs. So the first decision is architectural: active-passive or active-active.
Active-passive. One region serves all traffic; the second runs the full stack ready to take over. The consistency story is simple — one writer, replicated to the standby — but failover is a human-orchestrated event measured in 5-60 minutes, dictated by your RTO, and the passive region costs nearly as much as the active one while serving 0% of users. Failover latency is detection plus DNS TTLs — clients and resolvers cache answers for 30-300 seconds, so stale answers keep sending traffic to the dead region for minutes. And DNS latency routing is per-resolver, not per-device: thousands of users behind one ISP resolver route as a herd, and the route can be wrong for a significant fraction of them.
Active-active. Both regions serve — users in Europe hit eu-west-1, US users hit us-east-1. This is the only architecture where the latency win is real, sub-100 ms for both populations, and it is where the database breaks. Every write must reach every region. Synchronous replication makes every write wait the inter-region RTT — your write latency becomes ~75-85 ms of network time per write. Asynchronous replication keeps writes fast locally but buys replication lag, hundreds of ms to seconds under load and unbounded during partitions, and a failover may lose the last seconds of writes. Spanner pays the RTT and uses TrueTime clocks for linearizable cross-region writes; Aurora Global Database keeps writes local and pays with ~1-second failover RPO. That is a PACELC decision you make before you pick the architecture, not after.
The shape that usually wins: active-active at the edge, active-passive at the core. Stateless compute and static assets run everywhere — that part is cheap. The authoritative database stays in one region, read replicas fan out to the others, and writes travel back. You capture most of the read latency win with a fraction of the conflict machinery.
Edge cases. One cross-region dependency re-adds all the latency the architecture removed — a London user hitting an eu-west-1 frontend with the database in us-east-1 still pays ~70-80 ms per query. Idempotency keys for replayed writes, cache invalidation across regions, and per-region failover drills are the real work. If the interviewer pushes on split-brain: decide in advance which region owns each key, and make the loser's writes rejectable, not mergeable.