When a system keeps multiple copies of data, each read must have a defined relationship to writes. The CAP theorem defines consistency as returning the latest write or an error. Real systems choose a more specific guarantee per operation.
- Strong example
The illustrated write waits for required synchronous replication acknowledgement before returning success.
- Eventual example
Success returns before asynchronous replication completes, creating a stale-data window.
- Weak example
The illustrated replication can be dropped; the reader cannot rely on eventual propagation from this mechanism.
- Guarantee
Implement and document the actual consistency contract. Synchronous copying alone does not establish every strong-consistency guarantee.
Consistency depends on the guarantee and the required coordination, not merely having replicas.
How to read this model
A primary write fixture beside a replica with a selectable acknowledgement latch. The object is a teaching analogy. Inspecting a part highlights its role; it does not execute or simulate the software. Cabinet trays are records, workpieces are data, and latches are checks. Unless an explanation states a quantity, compartments and sample workpieces do not denote data counts. Part dimensions are not a quantitative scale.
Weak consistency
After a write, a read may or may not see it. The system makes a best-effort attempt to propagate the value. This can fit real-time media or multiplayer games, where missing a brief interval is preferable to delaying the live stream. Memcached commonly provides this style of cache behavior.
Eventual consistency
After a write, reads see it once asynchronous replication catches up. The delay is often milliseconds, but the interface must allow for a stale window. DNS and email use eventual propagation. This pattern fits highly available data where a temporary old value is acceptable.
Strong consistency
After a successful write, reads see that write. Replicas acknowledge synchronously, or reads go to an authoritative copy. File systems and transactional relational databases commonly provide strong guarantees within a defined scope. The cost is higher write latency and less availability during a partition.
Write down the stale-read and lost-write behavior that callers can observe. Then use caching and database replication with that contract in mind.