Skip to content

CONCEPT Cited by 6 sources

Eventual consistency

Eventual consistency is a liveness guarantee: if no new updates are made to a shared value, all observers will eventually converge on the same read. No bound is given on how fast convergence happens; correctness rests on convergence happening at all.

Contrast concepts/strong-consistency (read-after-write: any read after a write must reflect that write). Eventual consistency trades the synchronous-read-after-write guarantee for availability — readers get some value during partitions or transitions, not an error.

In auto-sharders

systems/dicer chose eventually-consistent Assignments: the Clerk (client library) and Slicelet (server library) maintain locally-cached Assignments and receive updates asynchronously from the Assigner. During transitions (split, merge, replication, move) Clerks and Slicelets may briefly disagree about which pod owns a given key.

The trade-off, per the Databricks post (Source: sources/2026-01-13-databricks-open-sourcing-dicer-auto-sharder):

  • Won: availability and fast recovery. Clients don't stall waiting for a coordinator; pods recover quickly after transitions.
  • Given up: strong key-ownership. Two pods may briefly think they own a key; applications either tolerate this or add their own mutex.

This is the same space systems/slicer and systems/centrifuge chose differently with leases — stronger ownership, at the cost of lease-refresh overhead and more complex failure-handling.

When eventual consistency is safe

  • Cache workloads — transient stale reads are fine; final-state correctness comes from the backing store.
  • Idempotent writes — double-owner transient state is absorbed by deduplication.
  • Read-mostly serving with a snapshot-consistent storage layer (e.g., systems/unity-catalog).

When it isn't

  • Exclusive-lock style workloads ("only one worker processes this job") need leases or consensus. Dicer's "soft" leader election (concepts/leader-election) names this limit explicitly.

Historical CAP framing (NoSQL default)

Most early NoSQL databases shipped eventual consistency as the default, prioritising Availability + Partition tolerance (AP) over Consistency under the CAP theorem. For roughly a decade this defined the market's perception of NoSQL as a category — even for exceptions like MongoDB, which was designed CP (Consistency + Partition tolerance) from the start and "was often lumped in with the rest, leading to the imprecise label of having 'light consistency'" (Source: sources/2025-09-25-mongodb-from-niche-nosql-to-enterprise-powerhouse). The adoption argument MongoDB later made against this framing — 70%+ of the Fortune 500, 7 of the 10 largest banks on MongoDB — is pitched as the empirical correction of the lumped-in categorisation.

The perception-vs-reality gap matters architecturally: during the decade when NoSQL = eventual consistency, system-of-record workloads (banking ledgers, medical records, order checkout) stayed on relational databases regardless of what the individual NoSQL database could actually guarantee. Closing the gap required per-operation knobs (tunable consistency) + multi-document ACID transactions as a demonstrable capability, not a category-wide rebrand.

Consistency as an AI-agent correctness prerequisite (2026-08-18)

The AWS "Consistency is the new latency" post reframes eventual consistency as an AI-reliability problem, not just an availability trade-off. When an autonomous agent's context window is its active memory, a stale read from an eventually-consistent replica "invalidates the agent's entire reasoning chain" — and a wrong conclusion written back accrues concepts/llm-hallucination. The prescription is not "always use strong consistency" but to match the guarantee to the task's truth requirement (consistency-matched-to-truth-requirement): strong/global consistency for high-stakes state, conditional writes for available shared memory, quorum reads for high-velocity intake. (Source: sources/2026-08-18-aws-consistency-is-the-new-latency-ai-at-the-data-layer)

Seen in

  • sources/2026-08-18-aws-consistency-is-the-new-latency-ai-at-the-data-layer — eventual consistency (async cross-region replication) framed as the root cause of stale-read failures in autonomous AI agents; the "replication trinity" prescribes when EC is acceptable vs when a stronger guarantee is required.
  • sources/2026-10-01-cloudflare-introducing-workers-kv-instant-powered-by-quicksilver — the counter-move to classic KV's eventual-consistency ceiling. Cloudflare shipped Workers KV Instant, a mode powered by Quicksilver that collapses the staleness window from classic KV's TTL (minimum 30s, see Browser Run below) to a ~250 ms p99 global write-replication fan-out from a single system of record — no TTL at all. Reads become 1.62 ms p99. The design directly targets the config-on-the-hot-path workloads for which eventual consistency was "too slow": instead of weakening the guarantee, Cloudflare exposed a different engine with a far tighter convergence bound. KV + KV Instant now coexist as two modes under one API — eventually-consistent (classic) vs near-instant single-writer replication (Instant).
  • sources/2026-05-13-cloudflare-browser-run-now-running-on-cloudflare-containers-its-faster — canonical wiki instance of eventual-consistency hitting its ceiling on an allocation hot path. Cloudflare's Browser Run tracked per-container allocation state in Workers KV until demand from AI agent builders outpaced KV's eventual-consistency window. KV's recently-reduced minimum cache TTL (60s → 30s, see 2026-01-30 KV changelog) was "still too high" for the workload; "You might check KV, see a container as 'available,' but by the time you route to it (30 seconds later), it's already claimed." The failure mode (race conditions + overallocation) is canonicalised as concepts/eventual-consistency — the subset of workloads that don't tolerate eventual consistency on the hot path. Migration to a transactional store (D1) closed the gap; KV retained for non-claim observability.
  • sources/2026-05-29-netflix-high-throughput-graph-abstraction-at-netflix-part-i — Netflix Graph Abstraction's strict-EC framing (multi-region async replication on KV + EVCache + Kafka entropy repair + LWW) as the strongest version of eventual consistency: convergence is guaranteed and deterministic — distinct from plain EC where convergence is guaranteed but the converged value isn't necessarily the same on every replica. See concepts/eventual-consistency for the refinement.
  • sources/2026-01-13-databricks-open-sourcing-dicer-auto-sharder — Dicer's explicit consistency choice; the prior-art systems (Slicer, Centrifuge) that chose differently.
  • sources/2025-09-25-mongodb-from-niche-nosql-to-enterprise-powerhouse — MongoDB's own framing of eventual consistency as the industry-default NoSQL posture it spent 15 years differentiating from; the historical context for why tunable consistency + multi-doc ACID mattered for enterprise adoption.

Client-readiness instance (2026-08-07)

Atlassian's Unleash PWA treats account provisioning, permission propagation, and Jira's post-write visibility as eventual-consistency intervals. Rather than block the product on convergence, it renders safe local/bundled data, queues intent locally, and lets authoritative live reads supersede the temporary state. This is a client-application instance of eventual consistency rather than a multi-replica datastore claim; see eventual-readiness and durable-client-outbox-with-settled-overlay. (Source: sources/2026-08-07-atlassian-building-a-real-time-pwa-on-atlassians-own-stack)

Merged aliases

  • eventual-consistency-too-slow-for-allocation
  • sla-based-eventual-consistency
  • strict-eventual-consistency- replica-divergence- durability-vs-consistency-guarantee
  • eventual-durability
Last updated · 766 distilled / 2,225 read