Strong consistency vs. eventual consistency

Strong consistency, in this comparison, means linearizability: after a write completes successfully, a later read returns that value or a newer one. The replicated data behaves like one current copy. With eventual consistency, a read may reach a lagging replica and return stale data, even data older than the client saw before. If updates stop and replication can proceed, replicas converge, but there is no promised deadline.

Strong consistency requires enough coordination to keep operations in a safe order. A system might use a leader, quorums, or synchronous replication; it does not have to update every replica at the same instant. Coordination adds latency, and an operation may wait or fail during a partition when the system cannot establish the required order. Eventual designs can serve reachable replicas and reconcile changes later, although eventual consistency alone does not guarantee availability.

Choose from the business rule. Reserving the last item needs an atomic conditional write or transaction with strong guarantees, as does a distributed lock. Temporary staleness is often acceptable for like counts or a search index. Many systems mix guarantees by operation, so define the required freshness, its scope, and what should happen when coordination is unavailable.