Eventual Consistency
A guarantee that replicas converge given no further updates, without guaranteeing when.
Eventual consistency is the weakest useful consistency guarantee: in the absence of new updates, all replicas will eventually agree. It says nothing about how long that takes or what anyone sees meanwhile.
It exists because of the CAP theorem's trade: a distributed system experiencing a network partition must choose between remaining available and remaining consistent. Choosing availability means accepting that different participants temporarily see different things.
For many systems that is obviously correct. A cached page, a feed, a counter, a search index — all tolerate being briefly behind. For others it is obviously wrong; a balance check that can be stale is not a balance check.
The design work is in making inconsistency legible rather than pretending it away. Showing when something was last updated, reflecting a local change immediately while it propagates, and reconciling honestly when the answer arrives are all better than an interface that implies certainty it does not have.
A specific, easily-missed instance: a cache whose scope is a single process behaves like a shared cache in development and like nothing at all across several instances, so a value written by one worker is invisible to the rest. That is eventual consistency with an eventuality of never. See Cache Invalidation.
See also8
Conflict-Free Replicated Data Type
A data structure whose replicas can be edited independently and always converge without coordination.
Networks & Distribution12 connections
Peer-to-Peer
An architecture where participants communicate directly rather than through a central server.
Networks & Distribution13 connections
WebRTC
The browser standard for direct peer connections carrying audio, video, and arbitrary data.
Networks & Distribution14 connections
Signaling Server
The small coordination service peers use to find each other before connecting directly.
Networks & Distribution10 connections
Write-Ahead Logging
Recording the intent of a change durably before applying it, so a crash can be recovered.
Computation & Algorithms20 connections
Idempotence
The property that performing an operation twice has the same effect as performing it once.
Systems & Tooling34 connections
Determinism
The property that identical inputs produce identical outputs, and the foundation of caching and verification.
Systems & Tooling61 connections
Key-Value Store
The simplest kind of database, which stores opaque values under unique keys and supports little more than get, put and delete, trading query power for speed and easy scaling.
Data & Content13 connections
Linked from20
- ACIDData & Content
The four guarantees a transactional database makes so concurrent, interrupted work never leaves data half-done.
- CAP TheoremData & Content
When a network splits a distributed system, it can stay consistent or stay available, but a proven theorem says not both.
- Change Data CaptureData & Content
Turning a database's own internal write log into a stream other systems can subscribe to, without touching the application.
- Conflict-Free Replicated Data TypeNetworks & Distribution
A data structure whose replicas can be edited independently and always converge without coordination.
- Content Delivery NetworkNetworks & Distribution
A CDN answers requests from servers near the requester, trading a single origin for many cached edges.
- Cross-Tab CommunicationWeb Platform
Keeping several open tabs of the same app consistent, best done by broadcasting small notifications and letting each tab re-read the truth.
- Database ReplicationData & Content
Copying the same data to multiple database nodes for redundancy and read scale, at the cost of a lag window.
- IdempotenceSystems & Tooling
The property that performing an operation twice has the same effect as performing it once.
- Isolation LevelData & Content
How much concurrent transactions are allowed to see of each other's unfinished work, a dial between correctness and speed that most databases set lower than people assume.
- Key-Value StoreData & Content
The simplest kind of database, which stores opaque values under unique keys and supports little more than get, put and delete, trading query power for speed and easy scaling.
- Materialized ViewData & Content
The stored result of a query, kept as a table so that expensive reads become cheap, at the cost of keeping that result up to date.
- Message QueueData & Content
A buffer that decouples a producer from a consumer in time, so neither has to be up, fast, or reachable at the same moment.
- Network PartitionNetworks & Distribution
A network failure that splits a cluster into groups that can't reach each other but keep running, and the split brain that follows when each side thinks it is in charge.
- Object StorageData & Content
Storage that keeps whole files as objects addressed by key in a flat namespace over HTTP, cheap and nearly limitless, which became the foundation for backups, media, and data lakes.
- Peer-to-PeerNetworks & Distribution
An architecture where participants communicate directly rather than through a central server.
- Signaling ServerNetworks & Distribution
The small coordination service peers use to find each other before connecting directly.
- Two-Phase CommitData & Content
A protocol for committing one transaction across multiple databases atomically, at the cost of blocking if the coordinator dies.
- WebRTCNetworks & Distribution
The browser standard for direct peer connections carrying audio, video, and arbitrary data.
- Write-Ahead LoggingComputation & Algorithms
Recording the intent of a change durably before applying it, so a crash can be recovered.
- Write-Behind CacheData & Content
A cache that acknowledges a write immediately and persists it to the real store later, trading durability for write latency.