We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Distributed Systems Core
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Distributed Systems Core
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
On April 21, 2011, Amazon's US-East-1 region suffered a massive network partition. A routine network configuration change went wrong, and a large number of EBS (Elastic Block Store) volumes lost connectivity to their replicas. The partition lasted hours. Reddit went down. Quora went down. FourSquare went down. Hundreds of services built on the assumption that "the network is reliable" crumbled.
Here's the thing that keeps distributed systems engineers up at night: you cannot prevent network partitions. You can reduce their frequency with redundant networking, better hardware, and careful configuration management. But you cannot eliminate them. Cables get cut by construction crews. Switches fail. Firmware bugs cause routing table corruption. One bad BGP announcement can partition entire regions of the internet.
Peter Deutsch and James Gosling listed "The network is reliable" as the very first of the eight fallacies of distributed computing. It was first on the list for a reason, it's the fallacy that causes the most damage when you believe it.
Understanding network partitions isn't academic. It's survival. Every design decision you make in a distributed system is ultimately an answer to the question: "What happens when nodes can't talk to each other?"
A network partition occurs when a group of nodes in a distributed system becomes unable to communicate with another group, even though nodes within each group can still communicate with each other.
Picture a cluster of five database nodes: A, B, C, D, E. During normal operation, they all exchange messages freely. Then a switch fails, and suddenly A, B, C can talk to each other, and D, E can talk to each other, but the two groups can't communicate. You now have two partitions: and .
Both partitions are independently functional. Nodes within each group think everything is fine, their peers are responding normally. But the cluster as a whole is split, and neither side knows the full picture.
| Partition Characteristic | Description |
|---|---|
| Asymmetric partition | A can't reach B, but B can reach A (one-way communication failure) |
| Symmetric partition | Neither side can reach the other |
| Partial partition | Some nodes can reach both sides (bridge nodes) |
| Total partition | Complete communication breakdown between groups |
| Transient partition | Brief connectivity loss that resolves on its own (seconds to minutes) |
| Sustained partition | Long-term connectivity loss requiring manual intervention |
The asymmetric partition is particularly nasty. Node A sends a message to node B and gets no response. Is B down? Is the network broken? Is B just slow? A can't tell. This ambiguity is the fundamental challenge, you can't distinguish between a slow node and a partitioned node.