Distributed System Basics
The problem
Once a system spans more than one machine, failure stops being all-or-nothing — the network between them can be slow, drop messages, or partition entirely, and any one machine can die while the others keep running. Distributed systems is the discipline of building correct software despite that new, unavoidable category of partial failure.
Why now
TCP and UDP already established that networks are unreliable at the packet level; processes and threads already established that a single machine can fail. Distributed systems is what happens when you stop being able to assume 'the network works' and 'the other machine is still alive' — assumptions single-machine programming gets to take for granted.
Mental model
A single-machine program either runs or crashes — you rarely have to reason about it being 'half-alive.' A distributed system is defined by exactly that possibility: some machines up, some down, some reachable, some not, all at once, and correct behavior has to be defined for every combination, not just the happy path where everything works.
Requires
- TCP & UDPNetworking
Distributed systems communicate over the exact unreliable, latency-prone network TCP and UDP already described; every distributed systems problem ultimately traces back to that network's imperfections.
- Processes & ThreadsOperating Systems
A distributed system is made of multiple independent processes, potentially on different machines; you need the single-machine process model already established before reasoning about many of them failing independently.
Unlocks
Used in
- Every multi-server backend architecture, from two servers behind a load balancer upward
- Understanding why 'it works on my machine' says nothing about distributed correctness
- The famous 'fallacies of distributed computing' (the network is reliable, latency is zero) as a checklist of wrong assumptions
- Designing for partial failure as a first-class requirement, not an edge case
Projects
- List five assumptions that hold true for a single-process program but become false once it's split across two machines, with a concrete failure example for each
- Simulate a network partition between two local processes (e.g. by blocking a port) and observe how an application that assumes reliable connectivity behaves
Examples
- A payment service and an email service running on separate machines: the payment can succeed while the email send fails, a state impossible in a single-process design
- A request that appears to hang isn't necessarily failing — it might be a slow network, not a dead server, and treating the two identically can cause duplicate side effects
Resources
Mastery checklist
- I can list several assumptions that break once a system spans multiple machines
- I can explain the difference between a slow response and a failed one, and why conflating them is dangerous
- I can design a simple two-service interaction that behaves correctly even if one service is temporarily unreachable
- I can explain why distributed systems must treat partial failure as normal, not exceptional