Serving a global user base with low latency and graceful handling of regional outages, active-active vs active-passive multi-region trade-offs, and the cross-region replication/consistency choice tied back to CAP theorem.
Published September 23, 2026
Design a system architecture serving users distributed across the entire globe with consistently low latency, that continues operating (at least for users outside the affected region) when one geographic region experiences an outage.
Functional: route each user's request to a nearby region for low latency; replicate necessary data across regions so any region can serve requests; detect and route around a failed region automatically. Non-functional: latency should stay low regardless of a user's geographic location; a single region's outage should not cause a global outage; the consistency model across regions needs to be explicitly chosen and understood, not accidental.
Active-passive: one PRIMARY region handles all writes (and typically reads too);
a SECONDARY region stands by, replicated but not actively serving traffic,
promoted to primary only during a failover
— simpler consistency story, but the secondary region's capacity sits mostly idle,
and failover takes real time (detecting the failure, promoting the secondary)
Active-active: MULTIPLE regions simultaneously serve live traffic (both reads
and writes), each handling requests from geographically nearby users
— better latency for a global user base (no requests forced to a single distant
region) and better resource utilization, but genuinely harder consistency:
writes happening in MULTIPLE regions concurrently need active conflict
resolution
This is a direct, consequential architecture choice, not a default — active-passive is meaningfully simpler to reason about and implement correctly (only one region ever accepts writes at a time), appropriate when failover time (typically seconds to low minutes) is acceptable and global write-latency isn't the primary concern. Active-active gives the best possible latency for a genuinely global user base and eliminates the idle-secondary-capacity waste, but requires the system to handle CONCURRENT writes to the same logical data from different regions correctly — a genuinely harder problem.
Strong cross-region consistency (every region always has the identical, latest
data): requires synchronous replication across regions -> real added latency
on every write (waiting for far-away regions to confirm), and reduced
availability during a cross-region network partition (CP, per CAP theorem)
Eventual cross-region consistency: writes replicate asynchronously -> low write
latency and high availability even during a partition, but a region can
briefly serve STALE data relative to a very recent write made elsewhere (AP)
This is HLD Fundamentals Refresher's CAP theorem discussion, made concrete at the GLOBAL, multi-region scale: synchronous cross-region replication genuinely can't avoid the physics of speed-of-light network latency between distant regions, making it a real cost on every write; asynchronous replication accepts brief staleness in exchange for both lower write latency and continued availability if a cross-region link is temporarily partitioned. As with E-Commerce Checkout & Inventory's mixed-consistency-model observation, different DATA within the same global system can reasonably make different choices — a user's profile data might tolerate eventual consistency fine, while a financial balance (Payment System) likely needs the stronger, more expensive guarantee.
Q: How does DNS-based or Anycast routing decide which region a user's request actually reaches? A: GeoDNS resolves a user's DNS query to the nearest healthy region's IP based on the user's approximate location; Anycast routing (the same IP address announced from multiple regions, with network-level routing delivering the request to the topologically nearest one) is a lower-level alternative achieving a similar effect — either mechanism is what actually implements the 'route to nearby region' requirement, sitting logically above the active-active/active-passive data-layer decision.
Q: What happens to in-flight requests when a region fails over during active-passive? A: In-flight requests to the failed region are simply lost/errored (the client needs to retry, ideally against the now-promoted secondary) — this failover window is exactly why active-passive's failover TIME matters as a real, user-visible metric, and why automated, fast failure detection (Health Checks-style liveness/readiness applied at the regional level) is critical to minimizing that window.
Q: How would active-active resolve a genuine write conflict (the same record updated in two regions nearly simultaneously)? A: Common approaches include last-write-wins (simple, but can silently discard one of the two updates), CRDT-based merging (Design a Distributed Counter's approach, when the data type supports it), or application-level conflict resolution logic specific to that data — there's no universal answer; the right approach depends entirely on what the specific data represents and what an acceptable resolution looks like for that specific case.
Q: Is this global-content-delivery architecture the same thing as a CDN, covered in Video Streaming Platform and S3? A: Related but broader — a CDN specifically caches and serves STATIC or semi-static content (video, images) at edge locations; global content delivery as covered here is about the full APPLICATION's architecture (including dynamic, write-heavy behavior) being distributed across regions, of which CDN-cached static content is typically just one, simpler piece.