MySmartCoPilot
Ask Passes Your pass 7 days left 1 day left Last day

Your country

Tools that support it use your country for local currency, number formats, units and paper size. Your choice is saved only in this browser.

System Design (High-Level Design) Module 8

Replication interview questions

Interview questions on replication: short warm-ups, then what each harder question tests, the first step of a good answer and its follow-ups.

17 questions: 3 warm-ups and 14 with model answers · Levels: Fresher to staff

Warm-up questions

Short questions with short answers, each answered in full.

  1. Fresher to mid

    What is the difference between synchronous and asynchronous replication?

    Answered in the lesson Leader-follower replication and replication logs

  2. Fresher to mid

    Why can statement-based replication leave a replica with different data?

    Answered in the lesson Leader-follower replication and replication logs

  3. Fresher to mid

    What are read-your-writes, monotonic reads and consistent prefix reads?

    Answered in the lesson Replication lag and read-your-writes guarantees

Questions with model answers

What each question tests, the first step of a good answer and the follow-ups to expect.

  1. Mid to senior

    Your orders database replicates asynchronously to two followers. At peak it takes 3,000 writes a second and replication lag reaches 400 ms. The leader's disk fails at peak. How many acknowledged orders can you lose, and how would you bound that number?

    What it tests
    The loss window of asynchronous replication, estimating it from write rate and lag, and choosing commit modes, alerts and recovery steps that bound it.
    First step
    Lost writes are the acknowledged writes the promoted follower had not received, so the loss is about the write rate times that follower's lag at the moment of failure: 3,000 × 0.4 s, or up to 1,200 orders at peak lag. Then ask how many lost orders the business can accept.
    Follow-ups

    From the lesson Leader-follower replication and replication logs

    Opening the model answers with your pass…

    Model answers open with any MySmartCoPilot pass.

    • Pro pass · 1 week₹79$2.99
    • 30 days₹179$5.99
    • 1 year₹1,699$45

    One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.

    Choose a passI have a licence key

    It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 4 minutes

  2. Senior to staff

    A team wants every commit to an orders database in Mumbai to wait for a synchronous standby in Singapore, about 3,900 km away, so that losing a whole region loses no order. What does that cost, and what would you propose instead?

    What it tests
    Latency floors of synchronous replication across regions, the availability cost when the remote standby is unreachable, and how to separate zone failures from region disasters.
    First step
    Start from physics: 3,900 km of fibre is at least 39 ms of round trip, so every commit waits at least that long, and a request with several writes in a row pays it each time. Then ask which failure the team fears: a lost server or zone, which is common, or a lost region, which is rare.
    Follow-ups

    From the lesson Leader-follower replication and replication logs

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  3. Mid to senior

    Your failover controller declares the primary dead after 3 missed heartbeats sent every second. Twice this month a 4-second garbage-collection pause on a healthy primary triggered a failover, and a few acknowledged writes were lost each time. How do you choose the timeout, and what else would you change?

    What it tests
    Failure-detector trade-offs between outage length and false failovers, and why a false failover costs data when replication is asynchronous.
    First step
    Write down both costs. A real crash costs roughly the timeout as a write outage; a false failover costs the asynchronous loss window and risks two leaders. A 4 s pause beats a 3 s timeout, so either the timeout must exceed the longest pause a healthy primary makes, or the pause must go.
    Follow-ups

    From the lesson Failover, split brain and fencing

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  4. Senior to staff

    After a network partition heals, you find that the old primary and the promoted standby both accepted writes for 30 seconds. What do you do with the old primary's writes now, and how do you make sure it cannot happen again?

    What it tests
    Handling divergent histories after split brain, bringing the old primary back safely, reconciliation, and fencing designs that prevent two writable leaders.
    First step
    Stop writes on the old primary at once, save a copy of everything only it accepted, and make the promoted standby the single source of truth before deciding anything else. Every later step is easier when the damage stops growing.
    Follow-ups

    From the lesson Failover, split brain and fencing

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  5. Senior to staff

    A job scheduler takes a 10-second lease from a lock service so that only one worker writes each job's result. Now and then a result is overwritten by an older run of the same job, yet the lock service never handed out two leases at once. How does this happen, and how do you fix it?

    What it tests
    Why leases alone cannot provide mutual exclusion when processes pause or clocks misbehave, and where the check that prevents stale writes must happen.
    First step
    Look for the gap between checking the lease and writing the result. A worker that checks, then pauses longer than the time left on its lease, writes after the lease has passed to another worker, and the lock service never sees that write.
    Follow-ups

    From the lesson Failover, split brain and fencing

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  6. Mid to senior

    Users report that after editing their profile, the page shows the old name for a few seconds, and sometimes the new name appears and then disappears on refresh. Reads go to three replicas behind a load balancer. Diagnose it, and fix it without sending every read to the primary.

    What it tests
    Recognising read-your-writes and monotonic-read violations from user symptoms, and choosing a routing fix with its costs.
    First step
    Name the two anomalies: the old name right after saving breaks read-your-writes, and new then old on refresh breaks monotonic reads. Both come from one user's reads landing on replicas at different log positions. Measure replica lag before choosing a fix.
    Follow-ups

    From the lesson Replication lag and read-your-writes guarantees

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  7. Senior to staff

    Your team sends a user's reads to the leader for one second after each write. Complaints about missing edits fall, but complaints that content jumps back to an older state rise. Explain why, and design a better routing rule.

    What it tests
    How a time window interacts with replica lag, and designing position-token routing with its operational details.
    First step
    Follow one session across the end of the window. Reads inside it come from the leader, which is always ahead; the first read after it can land on a lagging follower that is behind what the user has already seen. The window turns one anomaly into another.
    Follow-ups

    From the lesson Replication lag and read-your-writes guarantees

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  8. Senior to staff

    Your system uses log-position tokens for read-your-writes. After a failover, a few users find that writes they made a minute earlier are gone, although every follower they read from had passed their token. What happened, and how do you change the design?

    What it tests
    How log positions behave across a change of leader, and how to validate tokens so that a passed position really means the write is present.
    First step
    Start from what a token means: a position in one leader's log. Work out what the positions on the new leader refer to, compared with the old leader's, for writes the old leader acknowledged just before it failed.
    Follow-ups

    From the lesson Replication lag and read-your-writes guarantees

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  9. Mid to senior

    Your app has writable databases in two regions. A user changes their delivery address on a phone served by one region while a support agent changes it in the other, and last-writer-wins resolves the conflict. What can go wrong, and what would you change?

    What it tests
    Recognising silent data loss from last-writer-wins, the effect of clock skew, and avoiding conflicts by giving data a home region.
    First step
    Spell out what last-writer-wins does here: one of the two addresses is discarded and nobody is told, and if the regions' clocks disagree the older edit may be the one that survives. Then ask whether this data needs two writable regions at all.
    Follow-ups

    From the lesson Multi-leader replication and conflict resolution

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  10. Senior to staff

    Design sync for a notes app that works offline on a phone and a laptop. Both devices edit the same note while offline. How do you detect the conflict, what do you keep, and how do you stop deleted notes from coming back?

    What it tests
    Version vectors per device, handling concurrent versions, merging text and lists, and deletion markers with their clean-up.
    First step
    Give each device its own counter in a version vector stored with every note. On sync, compare the vectors: if one is ahead in every entry, take it; if each is ahead somewhere, the edits were concurrent and must be merged or both kept. A deletion has to be recorded, not inferred from absence.
    Follow-ups

    From the lesson Multi-leader replication and conflict resolution

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  11. Mid to senior

    A video platform counts likes in three regions, each with its own writable database. Design the like counter so that all regions agree in the end, users can remove a like, and repeated replication messages never inflate the count.

    What it tests
    Designing a counter that converges without coordination, merges that tolerate repeats and reordering, per-user semantics, and the limits of such data types.
    First step
    Start from the failure the prompt names: replication messages repeat and arrive in any order, so the merge must give the same result however often and in whatever order it runs. Then decide what each region owns, so that no two regions ever change the same number.
    Follow-ups

    From the lesson Multi-leader replication and conflict resolution

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  12. Mid to senior

    A shopping-cart service keeps each cart on N = 3 replicas of a leaderless store. Carts must keep accepting writes when one replica is down, and users must see their own change on the next page. Choose R and W, and say what can still go wrong.

    What it tests
    Choosing quorum sizes from failure tolerance and read-after-write needs, and knowing the gaps that quorums leave.
    First step
    Turn each requirement into an inequality: writes that survive one failure need W of at most 2, and reads that see the user's own write need R + W greater than 3. W = 2 and R = 2 satisfy both, and each operation then tolerates one failure.
    Follow-ups

    From the lesson Leaderless replication and quorums: N, R and W

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  13. Senior to staff

    Your store uses N = 3, R = 2 and W = 2, yet a support ticket shows a customer reading a new value and then an older one a moment later. A colleague says that is impossible because R + W > N. Who is right, and how could it happen?

    What it tests
    Precisely what quorum overlap guarantees and what it does not: reads during writes, failed writes, sloppy quorums and read repair.
    First step
    Separate the guarantee from the claim. Overlap promises that a read after an acknowledged write meets it; it promises nothing about reads that run while a write is still landing, writes that failed but partly landed, or writes accepted outside the key's usual replicas. Ask what was being written at the time.
    Follow-ups

    From the lesson Leaderless replication and quorums: N, R and W

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

  14. Senior to staff

    During a network partition your leaderless store can either accept writes for a key on substitute nodes, a sloppy quorum, or reject them. Which would you choose for shopping carts, and which for an inventory counter, and what must be in place either way?

    What it tests
    Trading write availability against consistency per data type, the limits of hinted handoff, repair, and conflict handling after the partition.
    First step
    Decide per data type by comparing what a rejected write costs with what a stale or conflicting write costs. A cart can accept writes and merge them later; a stock count that must never go below zero cannot be safely merged after the fact.
    Follow-ups

    From the lesson Leaderless replication and quorums: N, R and W

    In the answer:

    • Model answer
    • Follow-up answers
    • Common mistakes
    • Rubric
    • Variants
    • about 3 minutes

All System Design (High-Level Design) interview questions · The System Design (High-Level Design) track