Interview questions

Interview questions (with the counter-questions you'll get)

Q1. Why replicate a database?

They're testing: knowing the goals and the limits.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** For availability and durability (survive a machine failure), to scale reads across copies, and to serve users closer to where they are. It doesn't scale writes in the usual leader-follower setup, since every replica applies every write, and it isn't a backup, because mistakes replicate too.
3
4**Counter-questions:**
5- *"So how do you scale writes?"* → A bigger leader, or sharding (Chapter 15).
6
7**Trap:** saying replication is a backup.

Q2. Synchronous vs asynchronous replication?

They're testing: the core trade-off.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Synchronous confirms a write only after a follower has it, so confirmed writes survive a leader failure, but writes are slower and a slow follower can block them. Asynchronous confirms immediately and is fast, but the latest writes can be lost on failover. Semi-synchronous, waiting for one follower, is a common middle ground.
3
4**Counter-questions:**
5- *"What if the synchronous follower dies?"* → Writes stall unless the system falls back to another follower or to async, which some databases do automatically. Keep at least two candidates.
6
7**Trap:** not mentioning data loss on failover with async.

Q3. What is replication lag, and what problems does it cause?

They're testing: real-world experience.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** It's how far a follower is behind the leader. Users can fail to see their own writes, see data go backwards across reads from different replicas, or see effects before causes. Fixes: read-your-writes by reading from the leader or waiting for the follower to reach the write's log position, sticking each user to one replica for monotonic reads, and keeping related writes together.
3
4**Counter-questions:**
5- *"How do you measure lag?"* → From the database's replication status (log positions and replay delay), alerting when it grows and removing lagging replicas from rotation.
6
7**Trap:** "lag is a few milliseconds, so it doesn't matter".

Q4. How does failover work, and what can go wrong?

They're testing: depth on a hard operational problem.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Detect the leader's failure by missed heartbeats, choose the most up-to-date follower, promote it, repoint the other followers and the applications, and fence the old leader. Risks: losing asynchronously replicated writes, split brain if the old leader is alive, false failovers from timeouts that are too short, and a period of errors while clients reconnect.
3
4**Counter-questions:**
5- *"How long should the detection timeout be?"* → Long enough to ride out normal hiccups, short enough to keep outages brief; often a few seconds to tens of seconds, tuned from experience.
6
7**Trap:** describing failover as instant and lossless.

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

They're testing: distributed-systems fundamentals.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Two nodes both believe they're leader and accept conflicting writes, usually after a network partition. Prevent it with majority-based leader election (Raft or Paxos, often via etcd or ZooKeeper) so only one side can elect a leader, odd-sized clusters, fencing with term numbers so an old leader's writes are rejected, and leases that must expire before a new leader takes over.
3
4**Counter-questions:**
5- *"Why odd numbers of nodes?"* → A majority of 3 is 2, of 4 is 3. Four nodes tolerate only one failure, the same as three, at higher cost.
6
7**Trap:** "use a health check to decide who's leader".

Q6. When would you use multi-leader replication?

They're testing: knowing it's powerful but dangerous.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** For multi-region writes with low local latency and tolerance of inter-region link failures, for offline-capable clients, and for collaborative editing. The cost is write conflicts, which need a resolution strategy: last write wins (loses data), merging, asking the user, or CRDTs. I'd prefer giving each user a home region so each record still has one leader.
3
4**Counter-questions:**
5- *"Why is last-write-wins risky?"* → It silently discards a concurrent write, and it depends on clocks that differ between machines.
6
7**Trap:** choosing multi-leader without a conflict plan.

Q7. Explain quorums: N, W and R.

They're testing: leaderless replication.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** N is the number of replicas per item, W how many must confirm a write, R how many are read. If W + R > N, read and write sets overlap, so a read sees the latest write, with some edge cases. N = 3, W = 2, R = 2 tolerates one node down for both. Stale replicas catch up through read repair, anti-entropy and hinted handoff.
3
4**Counter-questions:**
5- *"Does W + R > N give strong consistency?"* → Not completely. Concurrent writes, sloppy quorums and failed writes that partly succeeded can still cause anomalies. It's strong-ish, not linearizable by default (Chapter 16).
6
7**Trap:** getting the inequality wrong.

Q8. How do you route reads between the primary and replicas?

They're testing: practical design.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Writes and reads that must reflect a user's own recent writes go to the primary; reads that tolerate slight staleness go to replicas. Implement it with separate connection pools or a proxy, stick a user to one replica for monotonic reads, give analytics its own replica, and remove replicas that lag too far.
3
4**Counter-questions:**
5- *"Isn't sending reads to the primary defeating the point?"* → Only the small share that need it. Most reads, like browsing, don't.
6
7**Trap:** "all reads to replicas".

Q9. Replication isn't a backup. Why not?

They're testing: operational wisdom.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Replication copies every change, including mistakes: a bad migration or an accidental delete reaches every replica in seconds. Backups and point-in-time recovery let you go back to before the mistake. You need both: replicas for availability, backups for recovery.
3
4**Counter-questions:**
5- *"What's point-in-time recovery?"* → Restoring a base backup and replaying the log up to a chosen moment, like just before the bad delete.
6
7**Trap:** treating replicas as backups.

Q10. A replica keeps falling further behind. What do you check?

They're testing: debugging.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Whether writes on the leader spiked (bulk jobs, migrations), whether the replica is overloaded by heavy read queries, whether it's on a smaller machine or slower disk, network throughput between them, and long-running queries on the replica blocking replay. Fixes: move heavy reads elsewhere, size the replica like the leader, batch bulk writes, and take it out of rotation until it catches up.
3
4**Counter-questions:**
5- *"What if the leader's write rate is simply higher than any replica can apply?"* → Then replicas can never keep up; you need to reduce writes, batch them, or shard (Chapter 15).
6
7**Trap:** only restarting the replica.
8
9---
10
11## Practice coverage
12
13Every section in this chapter is tested at least once.
14
15| Section | Tested by |
16|---|---|
17| 14.1 Why replicate | Q1, Q9 |
18| 14.2 Leader-follower | Level 3.1, Q1 |
19| 14.3 Sync vs async | Level 1B, Level 2.2, Level 5.1, Q2 |
20| 14.4 Replication lag | Level 2.1, Q3, Q10 |
21| 14.5 Fixes for lag | Level 1A.1, Level 1A.2, Level 3.2, Level 4, Q3 |
22| 14.6 Read replicas | Level 2.3, Level 5.2, Q8 |
23| 14.7 Failover | Level 1A.3, Level 3, Level 5.3, Q4 |
24| 14.8 Split brain | Level 1A.4, Level 5.3, Q5 |
25| 14.9 Multi-leader | Level 5.4, Q6 |
26| 14.10 Leaderless quorums | Level 2.4, Level 3.3, Q7 |
27
28---

14. Replication