Web fundamentals, an interactive architecture walkthrough
Multi-region active-active setup: how the architecture works
How an active-active setup serves users from several regions at once, replicates data asynchronously, and picks a consistency model per data type.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate.
Interactive diagram
Overview
A multi-region active-active setup serves users from two or more regions at the same time, each with a full copy of the application and its data, so users get local latency and the loss of a whole region does not take the product down. Global DNS or anycast sends each user to the nearest healthy region, and stateless app servers there read and write a local database replica.
Most writes are acknowledged by a quorum inside the region and replicated to other regions asynchronously, with last-write-wins on conflicts. Data that must merge concurrent updates, such as counters, uses CRDTs, and data that must never be accepted twice, such as unique usernames or balances, is written through a single home region. Events are copied between regional logs, and a health monitor drains a failed region. This is a simplified learning design, not any company's production setup.
Trade-offs and what changes at scale
Local writes give low latency and survive a region outage, but they mean conflicts and a short window of unreplicated data that can be lost on failover. Writing everything through one region avoids conflicts but brings back cross-region latency and a single point of failure for writes. Each region must have capacity for the others' traffic, which roughly doubles cost for two regions. At larger scale data is often partitioned so each user's records have a home region, keeping most writes conflict-free while still serving reads everywhere.
How it works, step by step
The walkthrough above, as text. Each step lights up the components named under it.
Users in Europe and the Americas resolve the same hostname, and Geo DNS / Anycast sends each to the nearest healthy region. Both regions serve traffic all the time, so neither is a cold standby.
In Europe the request reaches EU App Servers through the regional load balancer. App servers keep no state of their own, so any region can serve any user.
Reads and writes go to EU Database Replicas at LOCAL_QUORUM, which waits only for replicas in the same region. Users get local latency instead of a round trip across the Atlantic on every write.
The database replicates each write to US Database Replicas asynchronously, usually within a second. A US user may briefly see older data, which is accepted for this kind of data.
If both regions update the same record at once, the EU Database Replicas and the US copy both keep the write with the newer timestamp and the other is lost. That is acceptable for a profile photo but not for a balance, so data is classified before choosing where it may be written.
Counters, likes and session data go to CRDT Counters & Sessions, data types that merge concurrent writes from both regions without losing any. Two regions incrementing the same counter still end with the correct total.
Claiming a username goes to the Uniqueness Service, which writes it in one home region with strong consistency. Two regions accepting the same username independently could not be merged afterwards.
Each region publishes events to its own log, and the Event Replicator copies them to the other region under a prefixed topic name. Consumers can then process events from both regions without loops.
The Region Health Monitor probes each region end to end and, if one fails, tells DNS to send its users to the other. Each region keeps enough spare capacity to absorb the other's traffic.
During a failover, European users are served by US App Servers from the US replicas, minus any writes that had not replicated yet. That small window of possible data loss is the price of local writes.
Observability tracks replication lag between regions and conflict counts per table. Lag tells you how much data a failover right now would lose.
Sequence diagram
The same walkthrough as a UML sequence diagram, one lane per layer or group (17 components in all), left to right in the order a request reaches them, numbered by step. A loop on a lane is a step that stays inside that group. Solid arrows are synchronous calls, dashed are asynchronous.
Key components
Global Routingdomain
- Geo DNS / Anycast: sends users to the nearest healthy region
- Region Health Monitor: probes each region end to end
Userslayer
- Users in Europe: routed to EU region
- Users in the Americas: routed to US region
Region EUboundary
- EU App Servers: stateless, serve any user
- EU Cache: regional read cache (redis)
- EU Database Replicas: full copy of replicated data (cassandra)
- EU Event Log: regional events (kafka)
- EU Load Balancer: regional entry point
Region USboundary
- US App Servers: stateless, serve any user
- US Cache: regional read cache (redis)
- US Database Replicas: full copy of replicated data (cassandra)
- US Event Log: regional events (kafka)
- US Load Balancer: regional entry point
Cross-region Servicesdomain
- CRDT Counters & Sessions: merge-able data, written anywhere (redis)
- Event Replicator: copies events between regions
- Observability: replication lag, conflicts, region health
- Uniqueness Service: usernames, payments: one home region
Sources
Public writing this explainer draws on. Read these for what the real systems actually do.
Make it yours
Copy this diagram and its walkthrough into your own workspace, then change anything: swap Postgres for DynamoDB, add a cache, rewrite the narration. Free, and it uses no AI credits.
Related walkthroughs
- Distributed cacheHow a distributed cache places keys with consistent hashing, replicates shards, evicts entries, invalidates on writes and resists stampedes.
- Distributed key-value storeHow a Dynamo-style key-value store places keys on a hash ring, replicates them with tunable quorums, and repairs replicas that fall behind.
- Message queueHow a partitioned, replicated log stores messages durably, keeps them ordered per key, and lets consumer groups read at their own pace.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate. Real systems differ in the details. Browse the library.