Don't Panic — Distributed Systems Fundamentals

A distributed system is what happens when independent computers try to present one coherent service while the network keeps receipts in invisible ink. Each node has local state. Messages take time. A timeout tells the caller it stopped waiting, which is notably less useful than knowing what the server did.

The old plan was pleasantly compact: one process, or one database, made the decision and returned an answer. Distribution earns its keep only when a concrete requirement needs more capacity, lower latency near users, continued service after failures, or separate ownership. It also adds partial failure, concurrent events, and clocks that refuse to appoint themselves the universal narrator.

First keep partitioning and replication apart. Partitioning splits data or work so different nodes handle different pieces. Replication keeps copies so a failure or a distant reader is less disastrous. Most real storage systems do both, which is efficient until someone calls a hot partition a replication problem and the meeting becomes longer than the outage.

Then choose a consistency contract for the invariant that matters. Linearizability makes operations appear atomic in real-time order. Eventual consistency permits temporary disagreement and later convergence. Stronger coordination can make an invariant easier to protect, but it can add latency or pause progress during failures. Weaker coordination leaves more work running, while the application owns stale reads and conflicting versions.

Consensus is the arrangement for one durable shared decision. A replicated state machine works when replicas apply the same deterministic commands in the same order. Raft uses leader election, log replication, and majorities for that job. A majority side can commit new decisions; a minority side refuses to do so, which is frustrating only until it prevents two histories from becoming true at once.

Retries contain the surprise. At-most-once delivery can lose work. At-least-once delivery can repeat it. The useful outcome is often neither label but idempotency: a stable key lets repeated attempts represent one intended mutation, with durable duplicate handling behind it.

Read the intro for the full map of failures, causality, consistency, quorums, and recovery. Use the slides to see the relationships at a glance, and keep the cheatsheet nearby while reviewing a design. The Field Notes cover the operational costs that hide behind the tidy diagrams. The quiz is where the vocabulary has to choose a side.

Don't Panic — Distributed Systems Fundamentals

Relevant careers