Eventual consistency
Copies of data may briefly disagree after a write, but come to agree soon after.
Say two bank branches lose their phone line. They can refuse withdrawals until it's back, or keep paying out and risk mistakes. When the network between data centers breaks, a system must make the same choice: refuse some requests to stay consistent, or keep answering with possibly stale data to stay available. That's the CAP theorem in practice. Bank balances choose consistency. Like counts choose availability, with eventual consistency: copies agree soon, not instantly.
Try it now
Chains multiply, so every dependency costs you. Copies fail only if they all fail at once.
Learn it properly
System design fundamentals · Requirements, rough numbers, the standard parts and where systems break. About 40 minutes.
Other terms from the same lesson
- back-of-the-envelope estimate: Rough math, such as requests per second or storage per year, done before building to see which problems are real.
- CAP theorem: When the network between copies breaks, a system must choose: stay consistent and refuse some requests, or stay available and risk stale answers.
- consistent hashing: Placing servers and keys on a ring so that adding or removing a server moves only a small share of keys.
- non-functional requirement: How well a system must work rather than what it does: latency, scale, availability, consistency, cost and security.
- read replica: A copy of a database that serves reads, slightly behind the primary that takes the writes.
- sharding: Splitting data across several databases by a key, such as user id, so each holds only part of it.
- single point of failure: A part the whole system needs that has no backup, so its failure takes everything down.
Never trained an AI?
Teach a small one to write, right in your browser. It takes about 20 seconds and needs no account.