Eventually Consistent.

Vogels, W. (2009). Eventually Consistent. Communications of the ACM, 52(1), 40-44.

Type

Journal article

Intellectual base

Primary research

Year

2009

Volume

52

Issue

1

Pages

40-44

DOI

10.1145/1435417.1435432

DOI registrant

Association for Computing Machinery

Link

https://doi.org/10.1145/1435417.1435432

Cited from

cognitive_science, computer_science, logistics_supply_chain, systems_cybernetics

Cited by

8 citations across 8 artifacts.

Each citation links to the sentence it supports in the citing article.

Primes

• Bottleneck
  • Listed in the references but not attached to a specific claim.
• Concurrency
  • A common failure is designing for strong consistency without measuring the scalability cost, then being surprised by contention as load increases

    This sourceExplains eventual consistency and the consistency/availability trade-offs of replicated distributed data. SUPPORTS marker 060 (T4: scalability vs coherence — accepting eventual consistency at the cost of application complexity). DOI verified.

    Supported in partVerified against the publisher's abstract

    The abstract states that worldwide-scale distributed systems force trade-offs between consistency and availability, which backs the general cost-of-consistency frame but says nothing about scalability cost or contention surprises.

    “Building reliable distributed systems at a worldwide scale demands trade-offs between consistency and availability.”

    Read by an automated reader; not a human review. How support was checked

• Consistency Model
  • The management move is to match the guarantee to the operation rather than to the system as a whole — strong consistency for funds movement, eventual consistency for like-counts

    This sourceArticulates eventual consistency and the per-operation tiering of strong versus weak guarantees in large-scale systems.

• Eventual Consistency
  • The pattern compresses the design of a wide class of large-scale shared-state systems into four choices: which local writes are permitted without coordination; how changes propagate (push, pull, broadcast, gossip topology); how concurrent updates are merged (last-write-wins, version-vector, operational transformation, conflict-free replicated types); and what staleness bound the system advertises to its users.

    This sourceDefines eventual consistency, the staleness window, and the trade of consistency for availability and partition tolerance in large-scale distributed stores.

• Record-Reality Divergence
  • And cadence-to-stakes matching appears as the consistency-model choice: relaxed/eventual consistency tolerates staleness for speed where the stakes are low, while strong consistency forces near-synchronous reconciliation where correctness is critical.

    Supported in partVerified against the publisher's abstract

    The abstract attests only a consistency-vs-availability trade-off; it does not state that relaxed consistency trades staleness for speed at low stakes or that strong consistency forces near-synchronous reconciliation.

    “Building reliable distributed systems at a worldwide scale demands trade-offs between consistency and availability.”

    Read by an automated reader; not a human review. How support was checked

• Scalability
  • A common failure is choosing replication factors based on capacity concerns rather than failure-mode analysis, leading to either over-replicated systems that are expensive and slow to update, or under-replicated systems that fail when a single node fails
• Shared Mental Model
  • And the distributed-database vocabulary of consistency models — strong consistency, eventual consistency, read-your-writes, monotonic reads — gives a precise language for shared-model update disciplines

    This sourceDefines and contrasts distributed-database consistency models (strong, eventual, read-your-writes, monotonic reads), supplying the vocabulary for shared-model update disciplines.

    Supported in partVerified against the publisher's abstract

    Vogels's abstract establishes only that large-scale distributed systems trade consistency against availability; it does not name strong, eventual, read-your-writes or monotonic reads, nor any link to shared-model update disciplines.

    “Building reliable distributed systems at a worldwide scale demands trade-offs between consistency and availability.”

    Read by an automated reader; not a human review. How support was checked

Mechanisms

• Synchronization Job
  • The classic misuse is treating "synced" as "consistent" when the system is only eventually consistent

    This sourceExplains that an eventually consistent replicated store may temporarily return stale data even though replicas are converging.

Verification

Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.

Does it back the claim? Read against the text for 3 of 8 citations: 3 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.

Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.

See how references were verified.

Registry ID ref:5737a8f50cdc · see in the full table