Learning Distributed Systems in 90 Days

Distributed systems feel intimidating because the ideas arrive all at once. This plan splits them into phases so each concept builds on the previous one, and every phase ends with something you build or break.

Learning goals

By the end of this track you will be able to do the following.

Explain why networks, clocks and partial failure change system design
Compare replication and partitioning strategies with confidence
Describe how consensus protocols work at a conceptual level
Build a small replicated service and test it under failure

The plan

Weeks 1-2: Foundations

Study latency, bandwidth, failure models and the eight fallacies of distributed computing. Write a short note on how a simple client calling a server can fail in at least ten distinct ways.

Weeks 3-4: Time and ordering

Learn about physical clocks, logical clocks and vector clocks. Implement Lamport timestamps in a language you like and use them to order events across simulated nodes.

Weeks 5-6: Replication

Compare leader-based, multi-leader and leaderless replication. Build a key-value store with one leader and two followers, then inject a delayed follower and observe stale reads.

Weeks 7-8: Partitioning and consistency

Study hash partitioning, range partitioning and rebalancing. Read about consistency models from linearizable down to eventual, and map each to a product requirement you know.

Weeks 9-10: Consensus

Work through the ideas behind Paxos and Raft: terms, elections and log replication. Trace a leader failure on paper, then run a small Raft implementation and watch an election.

Weeks 11-13: Capstone

Combine what you learned into a replicated, partitioned store with a failure test suite. Document each design choice and the guarantee it provides, and present it to a peer.

How to use this plan

Treat each step as a block of roughly four to six focused hours per week, which fits alongside normal work. Keep a running journal with three headings: what I learned, what surprised me and what I will try next. Review the journal at the end of every step before moving on. If a step takes longer, extend it rather than skipping ahead, because later steps assume the earlier ones. Find a study partner if you can, since explaining ideas aloud exposes gaps quickly.

Common pitfalls

Reading papers without implementing anything
Memorizing protocol names instead of understanding failure cases
Skipping the fundamentals and jumping straight to consensus

Measuring progress

Check yourself against signals rather than feelings.

You can predict how a design behaves when a node is slow
Your capstone survives randomized failure tests
You can explain a trade-off without jargon

Learning sticks when it leaves your head. At the end of each step, post a short summary in a team channel or internal wiki, covering what you tried, what worked and what did not. Offer a thirty minute walkthrough to colleagues once per month. Feedback from people with different backgrounds will correct misconceptions early, and your notes become a starting point for the next person who follows the same path. Revisit this plan every quarter and adjust it to your changing role.

Exercises

Draw the message sequence for a write that succeeds on two of three replicas.
Break your store by dropping messages randomly and record which guarantees fail.
Explain the CAP trade-off to a non-engineer in three sentences.

Resources

Rather than pointing at specific links that may change, look for these kinds of material.

A widely recommended book on data-intensive application design
University lecture series on distributed systems with lab assignments
Original papers on consensus, read slowly with a study partner

Key takeaways

Partial failure is the defining problem, so design for it first
Implement each idea in miniature to make it real
Name the consistency guarantee you need before choosing a tool
Finish with a capstone that you can explain to others