eventual-consistency · shipping · also Eventually consistent replication

Eventual consistency

Eventual consistency requires replicas to converge after updates cease, assuming updates can propagate and conflicts are resolved.

Related Observatory article: Eventual consistency on hesela.com

The guarantee alone sets no fixed convergence deadline and does not imply read-your-writes or monotonic reads; these need additional contracts. Permanent communication failure prevents the propagation assumption from holding. [1]

Concurrent writes need a resolution policy, not necessarily a last-writer-wins timestamp. The 2007 key-value-store design can return divergent versions for application-assisted reconciliation. [2]

Relations

related
CRAQ, Linearizability, Session guarantees, Asynchronous replication, Anti-entropy repair

Citations

  1. Werner Vogels: Eventually Consistent - Revisited, 23 December 2008 (accessed 2026-10-22)
  2. Giuseppe DeCandia et al.: Dynamo: Amazon's Highly Available Key-value Store, SOSP 2007, section 4.4 (accessed 2026-10-22)

Further reading

  1. Hesela: Replication acknowledgements: received, durable, applied (accessed 2026-10-22)
Sources & caveats
  • Dynamo (SOSP 2007) is historical system evidence, not a claim about current DynamoDB APIs. [2]

JSON: /data/terms/eventual-consistency.json

Published by Hesela team · Updated

Report a correction · Editorial standards · Reuse guidance

Cite this page
Hesela team. Eventual consistency. Hesela. 2026-10-22. https://hesela.dev/terms/eventual-consistency/