Active-Active vs Active-Passive

Running more than one copy of the database is how you avoid a single point of failure — one crash taking the product down. The harder question is how those copies behave across regions — who can write, who only reads, and what happens when a site fails.

Two common shapes: active-passive and active-active.

A data center is just the physical place the stack runs — India and the US, or two regions in the same country. You run more than one so a fire, outage, or a bad day in one site does not take the product offline.

Active-passive

In active-passive, one data center (or one database) is primary. It takes writes. The others are replicas — read-only copies kept in sync for reads and disaster recovery.

Names vary: live, read-write, primary. Same idea. Writes from any region get redirected to that primary. The replica can serve reads. When new data lands on the primary, it syncs over.

Databases like MySQL, PostgreSQL, and Oracle typically sit here. They are not multi-master in the usual setup — multiple readers, one writer.

Writes hit primary only

Any region’s write is redirected to the primary data center

One live primary for writes. Replicas stay in sync for reads and disaster recovery — MySQL, PostgreSQL, and Oracle typically live here.

That works. It also leaves capacity on the table. A user writing from the far region pays cross-region latency to the primary. The replica is up and warm, but it cannot take writes.

When the primary dies

If the primary site fails, you promote a replica. Traffic moves. The product comes back.

Promotion is not free. Redirecting writes can take on the order of minutes. In that window, write requests may drop and the app feels broken until the new primary is ready.

Primary healthy

Writes land on primary · replica is standby

Disaster recovery works — but promotion is not instant. Expect a window where writes fail or queue until the new primary is ready.

Active-active

Active-active means more than one live primary. Both (or all) regions accept writes. Databases that support multi-master — Cassandra is the usual interview example — make this possible.

Different rows written in different regions sync cleanly. You use the hardware. Local writes stay local.

Both DCs accept writes

Multi-master — each region writes locally (e.g. Cassandra)

Multi-master databases let every region write. When rows don’t collide, sync is straightforward — and you actually use the spare capacity.

Same row updated in two places at once? That is a conflict. Sync alone is not enough — you need a rule. Common approach: each side keeps a change log, they exchange logs, and timing (or another policy) decides the winner. That design is its own topic; in an interview, naming the problem and a concrete resolution strategy is usually enough.

Same row, both sides

DC1 and DC2 both update row 1 at once

Active-active uses capacity fully — and pays for it with synchronization and conflict resolution. That problem deserves its own design, not a hand-wave.

One easy mix-up: these replicas are copies of the same database so the system stays up. That is different from a separate “read view” database built only to answer complex queries (sometimes called a CQRS read model). Same word “read,” different job — HA vs query shape.

Which one do you pick

Read-heavy, writes not the bottleneck → active-passive is often enough. Primary + replicas, DR path, simpler sync.

Write-heavy or you need local writes in every region → active-passive will bottleneck and hurt latency. You want active-active and a real answer for conflict resolution — not “we’ll figure sync out later.”

When not to use which

Don’t force active-active on a quiet, read-mostly product that is fine with one writer. You’ll buy conflict machinery you never needed.

Don’t stay active-passive when every region must write locally at low latency. Cross-region write redirect will show up in every p99.

Production pitfall

Calling the architecture “active-active” while every write still funnels to one master. That’s active-passive with better slides. If only one node can accept writes, say so — and plan failover, not fake multi-master.