What makes a system "Distributed"?
- Pradeep P
- 3 days ago
- 4 min read
Layer 1 · Post 1 of 15
← Previous: Layer 1 — The building blocks → Next: Requests, Responses and Latency
Layer 1 — The building blocks · Post 1 of 88
A system is distributed when work is split across machines that fail independently and must coordinate over an unreliable network.
What you'll learn
The difference between "more than one computer" and a truly distributed system
The two facts that cause almost every hard problem in this series
Why you cannot treat a cluster like a bigger laptop
The idea in one minute
If one program on one machine can do the whole job, you do not have a distributed system. You have a program.
A system becomes distributed when more than one machine shares the work, and those machines:
Can fail on their own. One box can die while the others keep running.
Talk over a network. Messages can be slow, lost, duplicated, or delayed.
Those two facts are the whole subject. Load balancers, caches, replicas, queues, and consensus exist because of them.
Why it matters
People often say "distributed" to mean "big" or "in the cloud." Size is not the definition. A tiny checkout service split across two VMs is distributed. A huge monolith on one beefy server is not.
This distinction matters because the rules change.
On one machine, a function call either happens or your process crashes. In a distributed system, you send a request and then live in uncertainty:
Did the other machine receive it?
Did it process it?
Did it process it twice?
Is it slow, or is it dead?
You cannot tell those apart by waiting forever. That is why later posts cover timeouts, retries, idempotency, and replication. They are not extras. They are how you survive the definition.
How it works
Picture two laptops on a desk.
Not distributed: The app, the database, and the files all live on laptop A. Laptop B is unused. If A loses power, everything stops. There is no coordination problem because there is nobody to coordinate with.
Distributed: The app runs on A. The database runs on B. They talk over Wi‑Fi. Now you have:
Partial failure. A is healthy, B is not — or the Wi‑Fi blips while both machines are fine.
No shared time. Each laptop has its own clock. "What happened first?" is no longer obvious.
No shared memory. A cannot look at B's RAM. It can only send a message and hope.
Add a third laptop for a cache, a fourth for search, and you have a typical web system. Each new machine adds capacity. It also adds new ways to be wrong.
A useful test: if one machine disappearing can leave the others in a confusing state, you are in distributed territory.
User
|
v
[ App server ] ----network---- [ Database ]
| |
+-------- can fail ------------+
independently
A simple example
You tap "Pay" in a food app.
The app server receives the tap and asks the payments service to charge the card. The payments service charges the card, then the network dies before the "success" reply comes back.
What does the app server know?
Maybe the charge happened.
Maybe it did not.
Maybe it happened and the reply is just late.
If the app server retries blindly, the customer might be charged twice. If it never retries, dinner never gets ordered. Neither choice is "just a bug in the code." It is the distributed nature of the work: two machines, one network, no shared truth.
A single-machine program never has this conversation with itself. A distributed system has it all day.
Common mistakes
Calling anything with two Docker containers "distributed systems design." Two processes on one laptop share a fate. Kill the laptop and both die. That is useful for local development. It is not the same as two processes in two datacenters.
Assuming the network is a function call. chargeCard() on the same machine either returns or throws. chargeCard() over HTTP can hang. Design as if every remote call might vanish.
Hoping clocks will save you. "We'll timestamp everything" does not decide order when machines disagree about the time. Later posts on consistency and leader election exist because of this.
Treating "the cluster" as one computer. A cluster is a group of computers pretending to be one. The pretending is the engineering.
How this shows up in real systems
Netflix, Amazon, your bank app: dozens to thousands of services. A checkout request may touch inventory, payments, fraud, email, and analytics — each on different machines.
A "simple" website: browser → CDN → load balancer → app → cache → database. Already distributed, even if one team owns it.
Kubernetes: pods move, nodes die, IPs change. The platform assumes machines are disposable. Your design has to assume that too.
When interviewers ask "design Twitter," they are not asking you to draw a single box. They are asking how you split work across machines that will not all stay up.
Recap
A system is distributed when independent machines coordinate over a network.
Independent failure and unreliable networks are the root of almost every later topic.
You do not get a bigger laptop. You get a set of computers that must agree, recover, and keep going when some of them cannot.
Once that click happens, the rest of this series is a catalog of tools for living with it.
Layer 1 · Post 1 of 15
← Previous: Layer 1 — The building blocks → Next: Requests, Responses and Latency
Comments