Active / Active Architecture
Serve traffic from multiple regions while making write ownership and conflicts explicit.
2–5 minute refresher
Leaderaccept writes
replicate ↓
Follower A
Follower B
Follower C
Multiple serving regions + explicit authority per operation + tested partition behavior
30second
refresher
refresher
Active / active architecture serves production traffic from multiple regions simultaneously. Reads are straightforward; writes require a clear strategy for ownership, global coordination, or deterministic conflict resolution.
What problem does it solve?
A single active region adds latency for distant users and creates a regional recovery event. Multiple active regions can improve locality and availability if data semantics support them.
How it works
- Define the regional failure and latency objectives.
- Route users to a healthy nearby region.
- Assign write authority by key, tenant, operation, or consensus group.
- Replicate durable changes and track lag.
- Define partition behavior, conflict handling, failover, and failback before launch.
Decision guide
Key trade-offs
| Choice | What you gain | What it costs |
|---|---|---|
| Single-writer key | Simple conflicts and invariants | Remote writes during owner loss |
| Multi-writer | Local write availability | Conflict semantics |
| Global consensus | Strong global order | Inter-region latency |
What happens if?
Regions can serve users but cannot reach each other
The design must choose per operation whether both sides continue, one side rejects writes, or authority is reassigned. Automatic dual promotion without fencing creates split brain.
Where it appears
- Global SaaS
- Multi-region commerce
- Edge APIs
- Global databases
Senior interview modeWhat questions must be answered before calling a design active / active?Show answer
Which regions accept which writes, how authority is established and fenced, what happens during partitions, how conflicts resolve, and how failback avoids replay or data loss.