Sign inStart practicing
Start practicing Sign in

Distributed Systems Roadmap: Replication, Consensus, Consistency

A distributed systems roadmap: failure models, replication and quorums, consistency, clocks, consensus with Raft, CRDTs and geo-replicated databases.

Advanced 3 min read · Updated

This distributed systems roadmap is an ordered path through the ideas behind databases, message queues and coordination services: why partial failure makes everything hard, how data is replicated and partitioned, how machines order events without a shared clock, how they agree through consensus, how replicas detect failures and repair themselves, and how real systems such as Dynamo-style stores, distributed SQL databases and collaborative editors combine these pieces.

Distributed systems interviews are less about naming algorithms and more about failure scenarios. For each step, practise answering: what happens if this message is lost, delayed, duplicated, or arrives after a node restarts?

Builds on the core system design roadmap. Do that first, or skip the parts you already know; this one only covers what distributed systems interviews go deeper on.

Tick topics off as you read them

  1. Step 1Why it's hard

    Partial failure and the limits of agreement.

  2. Step 2Replication

    Keeping copies of data on many machines.

  3. Step 3Partitioning

    Splitting data so it can grow.

    Practice:Distributed key-value storeDistributed systems · Advanced · Free

  4. Step 4Time and order

    Ordering events without a shared clock.

    Practice:Unique ID generatorDistributed systems · Beginner

  5. Step 5Agreement

    Consensus, leaders and locks.

    Practice:Leader election for a service clusterDistributed systems · AdvancedDistributed lock serviceDistributed systems · Advanced

  6. Step 6Membership and repair

    Detecting failures and converging replicas.

  7. Step 7Transactions across machines

    Atomicity when one database isn't enough.

  8. Step 8Putting it together

    How real systems combine these ideas.

    Practice:Distributed message queueDistributed systems · AdvancedGeo-replicated databaseDistributed systems · Advanced

Why the order matters

Each step answers a problem created by the one before it. Replication creates the question of which copy is correct, so you need consistency models and quorums. Partitioning creates hot partitions. Many replicas accepting writes create ordering problems, which is why clocks come before consensus. And once you understand all of them, systems like Dynamo and Spanner-style databases read as a set of choices rather than magic.

Key trade-offs to be able to argue

Trade-offOne sideOther sideGuide
Consistency vs availability under partitionRefuse requests to stay correct (CP)Answer with possibly stale data (AP)CAP theorem
Latency vs consistency without partitionsWait for a quorum or leaderRead the nearest replicaGeo-replication
Coordination vs convergenceAgree on one order with consensusMerge concurrent updates with CRDTsCRDTs
Atomic commit vs autonomyTwo-phase commit across servicesSagas with compensationSagas

A six-week plan

  1. Week 1: step 1. Write down every way a single RPC can fail and what the caller can and can't know afterwards.
  2. Week 2: steps 2 and 3. Work through N, R and W choices for a store, and design the key-value store round.
  3. Week 3: step 4. Explain why wall clocks can't order writes, and design the unique ID generator.
  4. Week 4: step 5. Walk through a Raft leader failure step by step, then design a lock service with fencing.
  5. Week 5: steps 6 and 7. Explain how two replicas find which keys differ, and when you'd accept a saga over 2PC.
  6. Week 6: step 8. Design a distributed message queue and a geo-replicated database.

Frequently asked questions

Do I need to read research papers?

Not for most interviews, but the Dynamo, Raft and Spanner papers are readable and worth it for senior storage or infrastructure roles. The guides here explain their ideas and link the originals.

Is this roadmap only for database engineers?

No. Any backend engineer whose services talk over a network benefits from steps 1 to 5. Steps 6 to 8 matter most for storage, infrastructure and platform roles.

Further reading