Start from zero: what a distributed system actually is
A distributed system is many computers cooperating as one, where the network and machines fail independently. This is the from-zero map and the eight words the rest of the track assumes you already know.
Your database query takes 2 ms on your laptop. Then someone says “we need to handle ten million users” and suddenly one machine is not enough. You add a second, then a third — and everything that was simple breaks in ways you did not expect. A write reaches node A but not node B before the network hiccups. Node C thinks it is the leader, and so does node D. A user reads their own update and then, a second later, reads stale data again. Nobody crashed. Nothing is “down.” Things just… disagree. Welcome to distributed systems — the discipline of making many computers cooperate as reliably as one, when the network between them cannot be trusted and any machine can fail at any moment. This lesson is the map before that climb.
The one problem distributed systems solve
A single machine has a hard ceiling: its CPU, RAM, and disk are finite. Beyond that ceiling you have two choices — buy a bigger machine (scaling up, with its own limits and costs) or add more machines and split the work (scaling out). Distributed systems are the second choice made rigorous. They also solve a second problem: a single machine is a single point of failure. Spread your data across three machines and you can lose one without losing the service.
The catch is that “many machines” means “connected by a network” — and networks drop packets, delay messages, and split into isolated islands. A machine can be slow without being dead. A reply can arrive after you gave up waiting. Two nodes can each believe they are in charge. These failure modes do not exist on a single machine, and the entire field of distributed systems is about handling them without making the system too slow or too complex to operate.
The eight words the rest of the track assumes
The senior units that follow drop these terms without stopping to define them. Here they are, one sentence each — what it is and why it exists.
| Word | What it is | Why it exists |
|---|---|---|
| Node | A single machine (server, process, or virtual machine) in the system. | So we have a unit of work and failure to reason about — the building block everything else composes from. |
| Partition (network split) | A failure where some nodes can no longer reach others over the network. | Because networks are unreliable — a partition is not a bug you fix, it is a condition you must survive. |
| Replication | Keeping copies of the same data on multiple nodes. | So the data survives a node failure and reads can be served locally without crossing the whole network. |
| Consistency | The guarantee that all nodes see the same data at the same time (or appear to). | So a user never reads stale or contradictory data — but strong consistency costs latency and availability. |
| Availability | The guarantee that every request gets a response, even during failures. | So the system keeps serving users — but returning a response may mean returning slightly stale data. |
| Latency | The time a message takes to travel between two nodes. | Because network hops add up — latency is the tax every distributed design pays, and it is never zero. |
| Partial failure | A state where some nodes work and others fail — simultaneously. | Because distributed systems can be half-broken in ways a single machine never is; you must handle it explicitly. |
| Consensus | A protocol by which nodes agree on a single value despite failures (e.g. Raft, Paxos). | So the system can elect a leader, commit a transaction, or decide anything — without one node having sole authority. |
How they fit together
Read in order, the words tell one story. You spread work and data across nodes for scale and fault tolerance. You use replication to keep copies of data on multiple nodes so no single failure destroys it. But now a partition can split the nodes into two islands that cannot talk. In that moment you face a forced trade-off: do you keep serving requests (prioritise availability) or refuse to answer until the network heals (prioritise consistency)? Either way, latency is the tax — every message between nodes takes time, and clocks on different machines drift apart. A partial failure means some requests succeed and others fail at the same moment, which is harder to reason about than total failure. Consensus algorithms are what nodes use to agree on facts (who is leader, what was committed) despite all of this. That trade-off between consistency and availability during a partition — called the CAP theorem — is exactly what Unit 01 digs into next.
▸Why this works
Why not just use one very powerful machine? You can, up to a point — and for many services that point is further than you think. The discipline of distributed systems is not that every system needs it, but that once you cross the threshold (too much data for one disk, too much traffic for one CPU, too much risk in one failure domain), you need a rigorous vocabulary for the problems that appear. Learning the vocabulary first makes the senior units land cleanly.
What makes a partial failure uniquely hard in a distributed system?
Order these concepts from the most fundamental to the most complex trade-off:
- 1 Node — the single machine that is the basic unit of the system
- 2 Replication — keeping copies of data across multiple nodes
- 3 Partition — a network split that isolates some nodes from others
- 4 Consistency vs availability — the forced choice when a partition occurs
- 01In one breath: what problem do distributed systems solve, and what new class of problems do they introduce?
- 02What is the consistency-versus-availability trade-off, and when does it bite?
A distributed system is many computers cooperating as one — connected by a network that cannot be trusted and populated by machines that fail independently. That combination introduces a class of problems absent from a single machine: partial failures where some nodes work and others do not, latency that can never be zero, clocks that drift apart, and the unavoidable trade-off between consistency and availability when the network splits. You spread work and data across nodes using replication, coordinate decisions using consensus protocols, and accept that exactly-once delivery and perfect consistency are not free — they cost latency, complexity, or availability. The eight words from this lesson — node, partition, replication, consistency, availability, latency, partial failure, consensus — are the vocabulary every senior unit assumes. Now when you read that “a partition forced a consistency-versus-availability trade-off,” you will know exactly what each of those words means and why the trade-off is real — not a design flaw, but physics. Next: Unit 01, the CAP theorem in practice.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.