Replication — Interview Cheatsheet#

When to mention replication#

"How do you handle DB failure?"          → replication + failover
"How do you scale read traffic?"         → read replicas
"What's your RPO?"                       → sync vs async replication
"How do you serve global users?"         → multi-primary + conflict resolution
Any system with > 10K read QPS          → read replicas

The standard move — always say this first#

Replication is simpler, safer, and sufficient for most read-heavy systems. Sharding is the escalation path.

Decisions to state explicitly#

Sync vs async — always justify

"I'd use async replication for low write latency. The trade-off is a small data loss window on failover, which is acceptable here because [reason]. For the payment ledger specifically, I'd use semi-sync — requiring at least one replica to confirm before returning success."

Replication lag + read-your-own-writes fix

"With async replication, replicas lag by milliseconds. To prevent read-your-own-writes violations — where a user updates something and immediately sees the old value — I'd route that user's reads to the primary for a short window after their write."

Failover

I'd use Patroni for automated failover. On primary failure it promotes the most up-to-date replica and redirects traffic — typically a 20-30 second write outage. To reduce data loss I'd configure semi-sync for critical writes.

Multi-primary (only if global)

"For a globally distributed system I'd use multi-primary so users in each region write to a nearby node. Conflict resolution: last-write-wins for non-critical data, single-primary routing for financial operations."

One-line definitions#

The RPO framing#