State and recovery
Whether two people looking at the system at the same moment see the same thing — and how long “eventually” is allowed to be.
Also called Eventual consistency · Согласованность
Strong consistency means a write is visible to everyone the instant it commits. Eventual consistency means it will be, later, and later is unbounded unless somebody bounded it. The trade is real: strong costs latency and availability, eventual buys both and hands you a window in which the system disagrees with itself.
The engineering question is never which is better. It is which reads may be stale and for how long, decided per case rather than per architecture. A dashboard thirty seconds behind is fine. A stock count thirty seconds behind sells the last unit twice. A balance thirty seconds behind is a regulatory conversation.
What makes this expensive is that the decision is usually never made. Eventual consistency arrives as a side effect of a cache, a read replica or a queue that somebody added for speed, and the window is whatever it happens to be. The failures then appear as unreproducible support tickets, because by the time anybody looks the system agrees with itself again.
A read replica or a cache in front of a query converts a strongly consistent read into an eventually consistent one, and nothing in the change announces it. Every place that read is used has silently acquired a staleness window nobody chose. Before adding one, name which reads may be stale and for how long; the ones that may not are the reason the cache needs a bypass.
The definitions are the easy part. Whether the figure on your dashboard was computed this way is a different question, and usually the more expensive one.