Tara builds ListMitra, a shared family shopping list. Her first users are her own family. Amma adds items from the kitchen, Appa from the office, and her brother Ravi from wherever he happens to be. (Tara's family, the app and every number here are made up for teaching.)
On day one, Appa adds "milk" while stuck in a lift with no signal. At the same moment, Ravi deletes "bread" at home. When both phones reconnect, what should the list say? And while they were apart, should Appa's phone have refused to show the list at all, just in case it was out of date?
That is the whole subject in miniature. When data lives on several machines, you must decide what a reader is allowed to see, and what you give up to guarantee it. Tara's first months produce one complaint after another:
| Complaint |
Idea it forces |
| "The app refused to open in the lift" |
CAP: choosing during a partition |
| "It's slow even when the network is fine" |
PACELC: latency versus consistency |
| "My edit vanished when I refreshed" |
The ladder of guarantees; session guarantees |
| "How many phones must agree before we say 'saved'?" |
Quorums: R + W > N |
| "Appa's milk got overwritten; his phone clock is wrong" |
Logical clocks |
| "We both added things offline; keep both" |
Vector clocks, conflict resolution, CRDTs |
| "The new family wallet must never be wrong" |
Choosing guarantees item by item |
This guide names those choices, so "consistency" stops being a vague word. It builds on Scaling data.
1. "The app refused to open in the lift": CAP, stated carefully
ListMitra keeps three copies of each list on three servers. When Appa's lift cuts him off, or when a cable between two data centres fails, some machines can't talk to others. That is a network partition.
The CAP result says that during a partition a system must choose between two things:
You've reached the free preview of this post.
Subscribe to the Blogs plan (₹99/mo) — or use any Algomi Suite, Career, Investor, or Trader plan — to keep reading.
See plans
