Database Replication Interview Questions: Leaders, Quorums, Lag, and Failover

A database can restore writes after failover and still lose a write that the old leader already told the client was successful. That apparent contradiction is exactly why replication interviews test more than vocabulary.

This guide covers database replication interview questions about leaders, quorums, lag, and failover. Each answer follows the same thread: where a write goes, when it becomes durable, which replica may serve it, and what happens when part of the system disappears.

Use PracHub to practice real interview questions with written solutions, then narrow your preparation with company-specific interview prep. Start with the failure scenario, state the consistency contract, and make every acknowledgement defensible.

A strong replication answer traces the write from the leader's log to acknowledgement, reads, promotion, and repair.

Quick Verdict: What a Senior Replication Answer Includes

A strong answer does not simply choose three replicas. It defines the write acknowledgement boundary, read policy, failure authority, and repair path.

Replication Model Interview Questions

1. What problem does database replication solve?

Replication keeps multiple copies of data so a system can survive machine failures, move reads closer to users, or spread read traffic. It can improve availability and read capacity when the application has a clear policy for which copy is authoritative.

Replication is not a backup. A bad delete, corrupted update, or compromised credential can affect every replica. It also does not automatically scale writes when one leader still serializes all changes.

2. How do leader-follower and leaderless replication differ?

In leader-follower replication, clients send writes to a leader, which orders changes in a log and forwards them to followers. Reads may go to the leader or eligible followers, while failover must establish one new write authority.

Leaderless systems can accept a write through any coordinator and send it to several replicas. They rely more heavily on per-operation consistency levels, version comparison, conflict resolution, hinted handoff, and repair. These models use similar words such as quorum, but do not promise identical behavior.

3. How does log-based replication work?

The leader first records an ordered change in a durable log, such as PostgreSQL's write-ahead log. Followers receive log records, persist them, and replay them to advance their local database state.

This creates useful progress markers: generated, sent, received, flushed, and replayed. Those stages matter because a follower can possess bytes on disk without having applied them for queries yet.

4. What is the difference between synchronous and asynchronous replication?

With asynchronous replication, the leader can acknowledge before a follower confirms the write. Latency and write availability are better, but a sudden leader loss can discard acknowledged changes that never reached the promoted replica.

Synchronous replication waits for a configured acknowledgement before commit returns. That shrinks the data-loss window, but adds network and replica latency and can block writes when the required acknowledgement set is unavailable.

5. How is replication different from sharding?

Replication copies the same logical data to multiple nodes. Sharding partitions different data across nodes, usually by a key, to increase storage and write capacity.

Real systems often combine them: each shard has its own replication group. The interview then has two failure questions, because the design must route to the right shard and keep that shard available.

Quorum and Consistency Interview Questions

6. What does W + R > N mean?

For a replicated item stored on N replicas, a write acknowledged by W replicas and a read consulting R replicas have at least one overlapping replica when W + R > N. With replication factor three, W=2 and R=2 overlap.

Overlap is useful, but the equation alone does not prove linearizability. The system must also select the latest valid version correctly, handle concurrent writes, and define what happens during coordinator failures and clock disagreement.

7. Does majority write acknowledgement make a database strongly consistent?

No. Majority acknowledgement describes how many members confirmed a write; it does not, by itself, define how later reads are routed. A read from a delayed follower can still return an older value.

Strong consistency requires a complete protocol: authoritative ordering, safe leader election or version selection, and a read path that cannot bypass committed state. For example, MongoDB distinguishes majority read concern from its stricter primary-only linearizable read concern.

8. How would you guarantee read-your-writes?

The simplest option is to send a client's post-write reads to the leader. Other designs keep the session on a sufficiently current replica or return a commit position with the write and require a replica to reach that position before serving the next read.

If no eligible replica catches up before the deadline, fall back to the leader or return a clear error. Quietly serving stale data violates the session contract.

9. How do leaderless databases handle concurrent writes?

Replicas need metadata that reveals whether one version follows another or whether writes are concurrent. Depending on the product, resolution may use logical versions, application merges, last-write-wins rules, or data types designed to converge.

A senior answer calls out the business consequence. Last-write-wins may be acceptable for a replaceable profile setting, but it is dangerous for inventory or account balances where silently discarding one update is not a valid merge.

10. What is split brain, and how do you prevent it?

Split brain occurs when two nodes both believe they may accept authoritative writes. A majority-based election helps ensure only one leader wins a term, but external side effects also need protection from an isolated former leader.

Use monotonically increasing terms, epochs, or fencing tokens. Storage systems and downstream services should reject work from an older token, so a stale leader cannot continue changing shared resources after a new leader is elected.

Replication Lag and Stale Read Questions

11. What causes replication lag?

Lag can originate at the leader, in the network, on follower storage, or during replay. Bursty writes, large transactions, slow disks, lock contention, insufficient apply workers, bandwidth limits, and long-running follower queries are common causes.

Do not answer only with "network latency." First identify the stage that stopped advancing, then connect it to a resource or workload bottleneck.

12. How should replication lag be measured?

Compare log positions across generation, send, receive, flush, and replay. A widening send-to-receive gap suggests transport or receiver trouble, while a widening flush-to-replay gap points to apply pressure.

Track both bytes or log distance and elapsed time. Wall-clock delay alone can be misleading during a quiet period, and a small time delay can still contain a large burst of important writes.

13. When is it safe to serve reads from replicas?

It depends on the product contract. Search results, analytics, and feeds may tolerate bounded staleness; payment confirmation, permissions, or read-after-write screens often cannot.

Route by requirement, not by a global "reads go to replicas" rule. Exclude unhealthy or overly delayed replicas, use a commit-position fence for session reads, and send strict reads to an authoritative path.

14. What happens when a follower falls behind the retained log?

If the leader still retains every required log record, the follower can stream the missing range. If that history has been recycled, the follower needs a new snapshot or base backup and then replays changes from that checkpoint.

Retention mechanisms must be bounded and monitored. PostgreSQL replication slots, for example, can preserve WAL for a delayed standby, but an abandoned slot can retain enough WAL to exhaust storage.

15. How do you repair inconsistent replicas?

Leader-based systems usually catch up from the log or rebuild from a snapshot. Leaderless systems also need read repair or anti-entropy processes that compare replicas and reconcile missing or divergent data.

Best-effort hints are not a complete repair strategy. Apache Cassandra documents hinted handoff and read repair as best effort, with anti-entropy repair required to maintain consistency over time.

Leader Failure and Failover Interview Questions

16. How should a new leader be elected?

A failure detector suspects the leader after missed communication, then eligible members vote in a new term. In Raft, a candidate needs votes from a majority, and the voting rule prevents a candidate with an older log from replacing a more up-to-date one.

The timeout is an availability trade-off, not proof of failure. A short timeout reacts quickly but can cause needless elections during pauses or packet loss; a long timeout extends outage recovery.

17. How do RTO and RPO shape failover?

RTO is how long the service may take to recover. RPO is how much accepted data the business can lose. Async cross-region replication may support a short RTO but still have a non-zero RPO.

State the acknowledgement boundary before promising zero data loss. If a write returned after only the old leader persisted it, promotion of a lagging follower can lose that acknowledged write.

18. What happens when the old leader comes back?

It must not immediately accept traffic. First fence and demote it, compare its history with the current leader, then rewind, roll back, or fully re-seed it before rejoining as a follower.

MongoDB documents that writes from the former primary can be rolled back if they were not replicated to the majority before another member became primary. The application must therefore make retries idempotent and reconcile ambiguous outcomes.

19. How would you perform a planned failover?

Stop or drain new writes, verify the target has reached the required log position, transfer authority, update routing, and fence the former leader. Resume traffic gradually while monitoring errors, lag, and rejected stale-term requests.

A planned exercise should test more than election. Validate DNS or proxy behavior, connection pools, client retries, cache invalidation, background jobs, and the process for returning the old node safely.

20. How would you design replication across regions?

Start from latency, failure domains, and the business RPO. A common design acknowledges to a same-region standby for local durability and replicates asynchronously to another region for disaster recovery; it keeps normal latency lower but leaves a regional loss window.

Cross-region synchronous acknowledgement can narrow that window, but every write pays wide-area latency and may lose availability during a partition. Multi-leader or leaderless designs move the trade-off into conflict handling, ordering, and data ownership.

Trace one write through the log and acknowledgement boundary, then prove that promotion fences the old leader and repairs every replica.

Worked Scenario: A Multi-Region Order Database

Suppose an order service has one leader and a synchronous standby in region A, plus an asynchronous disaster-recovery follower in region B. The API acknowledges an order only after the leader and local standby have flushed it.

If the leader alone fails, the local standby is the safest promotion candidate because it participated in the acknowledgement. Critical post-write reads go to the leader or to a replica that has reached the order's commit position; analytics may use a bounded-stale follower.

If all of region A disappears, region B can restore service, but its last replayed position defines the regional RPO. The old region remains fenced when it returns, clients retry with order idempotency keys, and operators reconcile any ambiguous requests before rebuilding followers.

This answer is stronger than "use three replicas." It names the commit point, failover candidate, stale-read rule, regional data-loss boundary, client retry behavior, and repair process.

What Interviewers Are Actually Scoring

Junior answers identify leaders and replicas. Mid-level answers compare sync and async replication and explain lag. Senior answers make the acknowledgement boundary, read contract, election authority, fencing, repair, RTO, and RPO explicit.

Interviewers also watch whether you reason through uncertainty. A client timeout does not prove a write failed, a majority acknowledgement does not define every read, and restoring availability does not prove every acknowledged write survived.

Use PracHub's system design questions to practice those trade-offs. Senior loops also score incident ownership and cross-team communication, so include behavioral and leadership practice in your final prep.

A Five-Step Framework for Any Replication Question

1. Draw the topology. Name leaders, followers, regions, voting members, and failure domains.

2. Define commit. State where the log is durable, which acknowledgements the client waits for, and what a timeout means.

3. Define reads. Specify which nodes may serve each read, the allowed staleness, and how sessions observe their own writes.

4. Walk the failure. Explain detection, election, promotion, routing, retries, and how stale leaders are fenced.

5. Close the loop. Show how lag is measured, divergent replicas are repaired, the old leader rejoins, and the RTO/RPO are tested.

Frequently Asked Questions

Is replication the same as backup?

No. Replication maintains live copies for availability and read scaling, so accidental or malicious changes may propagate quickly. Backups preserve recoverable historical state and should be independently retained, protected, and restore-tested.

Can asynchronous replication lose committed data?

Yes. "Committed" may mean durable only on the old leader. If that leader fails before a follower receives the change, promoting the follower can lose a write that the client already saw as successful.

Does quorum mean strong consistency?

Not automatically. Quorum overlap is one ingredient, but the guarantee also depends on version selection, election safety, concurrent-write handling, and which replicas may serve reads. Ask what the specific database protocol promises.

How much replication lag is acceptable?

There is no universal threshold. Derive it from the read contract and recovery objective: a feed may tolerate seconds, while authorization or payment confirmation may require the latest committed position. Alert on both user impact and stage-specific lag.

How do you prevent split brain?

Require a quorum to grant leadership, attach an increasing term or fencing token to authoritative work, and make shared resources reject stale tokens. Election without fencing may still let an isolated former leader produce external side effects.

Final Takeaway

The best database replication interview answers trace one write through success and failure. Define who owns writes, when the client receives success, which reads may be stale, who can promote a replacement, and how the system proves the old leader is no longer authoritative.

Practice that reasoning with realistic prompts in PracHub's interview question library. Repeat each scenario until you can state the durability boundary, consistency guarantee, and recovery cost without hiding behind the word "quorum."

Official Sources

PostgreSQL: Warm Standby and Streaming Replication documents WAL shipping, asynchronous and synchronous replication, receive/flush/replay positions, promotion, replication slots, and quorum synchronous standbys.

Apache Cassandra: Dynamo Architecture documents consistency levels, quorum calculations, read/write overlap, hinted handoff, read repair, and anti-entropy repair.

The Raft consensus paper supports the majority election, log-safety, commit, and linearizable-read boundaries discussed here. MongoDB's official documentation covers replica set rollbacks, read concern, and write concern.