How do you design a multi-region DB for HA and DR?

Question

IT Interview Practice · Accepted Answer

Replicate the database across regions and choose your topology by need: **active-passive** (one writer, a warm standby that takes over on failover) for simplicity and strong consistency, or **active-active** (multiple writers) for low write latency at the cost of conflict resolution — then pick **sync vs async replication** to trade durability against latency, and define explicit **RPO/RTO** targets driving failover.

```text
        ┌──────────── Region A (primary) ────────────┐
writes ─▶ app ─▶ DB primary ──┐
                              │ replication
        ┌─────────────────────┼── async (RPO>0) ─────┐
        │                     └── sync (RPO=0, slow)  │
        ▼                                             ▼
   Region B standby                            (failover promotes standby)
        │
   health check ──▶ on primary loss: promote + repoint DNS/traffic
```

## Active-passive vs active-active

**Active-passive** has one primary handling writes and standbys that only read; on failure you **promote** a standby. It is simple and avoids write conflicts, but the passive capacity sits idle and failover has a gap. **Active-active** lets every region accept writes for local latency and no failover promotion — but two regions can edit the same row concurrently, so you *must* resolve conflicts (last-write-wins, CRDTs, or app-level merge). Most teams start active-passive; active-active is for global write latency you genuinely can't otherwise meet.

## Sync vs async replication

This is the core durability/latency trade. **Synchronous:** the primary waits for the remote replica to acknowledge before committing — **RPO = 0** (no data loss on failover) but every write pays cross-region round-trip latency (~tens of ms), and if the replica is unreachable, writes stall. **Asynchronous:** the primary commits locally and ships changes after — fast writes, but a region loss can lose the last few seconds (**RPO > 0**). Cross-region sync is often too slow, so many run async and accept a small RPO.

## Failover, RPO & RTO

- **RPO (Recovery Point Objective):** how much data you can lose — set by sync vs async.
- **RTO (Recovery Time Objective):** how long until you're back — set by how fast you detect failure and promote.
- Failover = detect (health checks) → promote standby → repoint traffic (DNS/global LB). Automate it, but guard against **split-brain** (both regions think they're primary) with a quorum/fencing token.

## Interview perspective

The probe: do you understand that HA/DR is a **trade between consistency, latency, and data loss** — not "just add a replica". Good: active-passive with a standby. Great: you state RPO/RTO, sync-vs-async implications, and the split-brain risk. Trap: claiming async gives zero data loss, or assuming failover is instant and lossless.

## Trade-offs & failure modes

- **Split-brain:** network partition promotes two primaries → divergent data. Use quorum, fencing, or a witness region.
- **Failback is hard:** after the old primary returns, reconciling divergent writes is manual and error-prone.
- **Cost:** true multi-region roughly doubles infra and adds cross-region egress bandwidth bills.
- **Untested failover fails:** DR that's never drilled won't work in the real outage — run game-days.

Active-passive vs active-active

Sync vs async replication

Failover, RPO & RTO

Interview perspective

Trade-offs & failure modes

Related questions