Large Language Thing

Home/Concepts/Eventual consistency: why continuous ingestion follows

Eventual consistency: why continuous ingestion follows

Any system that acts on beliefs about a changing world owes its operator a staleness bound. Distributed computing worked this out decades ago: you may serve stale reads, provided…

The guarantee, before anyone mentions models

A distributed data store keeps several copies of the same fact. Copies drift apart the moment a write happens to one and not, yet, to the others. Eventual consistency is the specific promise a system makes about that drift: if writes stop, every replica will converge on the same value. It is a guarantee about the future of a system at rest, not a description of its present. At any given instant a read may return an old answer. What makes the arrangement disciplined rather than sloppy is that the staleness is bounded and named. A system can state how far behind a replica is allowed to fall, what process forces it back into agreement, and how long that process takes.

That last part is the substance. Anti-entropy repair runs on a schedule and reconciles replicas that have quietly diverged. Vector clocks let two versions of the same record be compared and ordered without a central referee. Hinted handoff queues hold writes destined for a replica that is temporarily unreachable, so they arrive once it returns. Read-repair fixes a stale value the instant a client happens to notice it. None of these mechanisms make the data fresh. They make the lag measurable and self-correcting. Staleness with a convergence guarantee is a different category of thing from staleness with no guarantee at all — the first is a designed trade-off, the second is an unmanaged risk that happens to look, on a good day, like data.

Once you see the distinction it applies well outside databases. The Network Time Protocol never claims a machine's clock is correct. It maintains a dispersion estimate, growing at a modelled drift rate between synchronisations, so the machine can report the width of its own uncertainty — routinely tens of milliseconds, sometimes more. The clock is stale continuously and says so. That self-reported error bar, not the accuracy of the clock, is the engineering achievement.

Where it came from

Eric Brewer named the tension at a 2000 PODC keynote, arguing that a distributed system cannot simultaneously give perfect consistency, full availability and tolerance of network partitions — the CAP conjecture. Seth Gilbert and Nancy Lynch gave it a formal proof in 2002. The practical vocabulary came from Werner Vogels, writing in 2008 out of Amazon's experience running Dynamo across data centres that would, inevitably, sometimes stop talking to each other. The problem was not academic. Refusing writes during a partition meant refusing sales. Amazon's Dynamo paper, published at SOSP in 2007, described shopping carts kept available under a quorum scheme where the number of replicas needed for a read plus the number needed for a write could be less than the total replica count — deliberately, to keep the cart open under partition. Conflicting versions were reconciled by merging, which meant a deleted item could reappear in the cart later. Amazon accepted that specific anomaly because it was named in advance, bounded, and its business cost was already known. The field's contribution was never the discovery that data goes stale — every engineer already knew that. It was the insistence that staleness be specified, measured and contracted, rather than tolerated silently and discovered in production.

Azure Cosmos DB later turned this into a menu: five consistency levels sold as an explicit contract, including a Bounded Staleness mode where the operator sets a maximum of K versions or T seconds of lag, backed by a service-level agreement with financial penalties for breach. Staleness there is a purchased parameter, not an accident absorbed after the fact.

The turn

A Large Language Model is a replica that stopped accepting writes. Its corpus was collected once, up to a cutoff date, and frozen. That would be an ordinary, defensible trade-off — plenty of distributed systems run happily on stale reads — except that it carries none of the instrumentation that makes staleness defensible elsewhere. There is no anti-entropy process reconciling the model's beliefs against the world. No read-repair fires when a stale answer is served. No vector clock orders an old fact against a newer contradicting one. No dispersion estimate grows between training runs the way NTP's grows between synchronisations. A retraining run does not repair the existing replica; it stands up a new one, with a new cutoff and an equally unstated, equally unbounded lag. The model has staleness without a guarantee. That is the exact configuration eventual consistency was invented to rule out.

The Large World Model narrows the window without closing it. While its sensors are live, it has something like a consistency bound: beliefs track a scene in something close to real time. The instant the camera turns away, the guarantee lapses, because nothing was left open to re-check against. Its convergence is scoped to the duration of an episode of sensing, not to the world.

The Large Universe Model is the position where the guarantee becomes statable at all, because the condition eventual consistency requires — an open channel back to the source — is satisfied by construction. Streams stay live. A belief is not just a value but a value with a last-confirmed timestamp, a source, and a re-check policy, the way a Dynamo record carries a vector clock and a Cosmos DB read carries a session token. That is what lets an operator say: this fact may be six hours stale, this mechanism forces it back into agreement, here is the interval. Nobody can say the equivalent sentence about a frozen model's weights.

The misreading to disown

The tempting shortcut is: fresh beats stale, therefore more intake wins, therefore continuous ingestion is simply better. That argument is weak and worth refusing on its own terms. Stale data is frequently perfectly adequate — the boiling point of water has not needed re-checking since it was last measured, and querying it nightly would be waste, not rigour. Freshness has real cost: bandwidth, compute, noise, false urgency. The claim here is not that recent beats old. It is that a bound beats no bound. A system reading a replica it knows to be six hours old is under control. A system reading a replica of unknown age is not under control, even in the case where that replica happens to be fresher. What continuous intake buys is provenance and an auditable bound, not speed for its own sake.

Recency is the seductive version of this argument and the wrong one; the load-bearing term is the bound, not the freshness.

Taking the objections seriously

Eventual consistency assumes writes eventually stop. The real world never stops writing. A model chasing a permanently moving target may never converge — you've swapped an honest freeze for a system permanently, invisibly mid-repair.

This is correct about the idealised limit, and it narrows the claim. No practitioner ever relied on that limit in production; they relied on operational numbers instead — replica lag measured in milliseconds, repair-completion rates, Cosmos DB's explicit K-versions-or-T-seconds bound. Those are meaningful under permanent write traffic. The same move applies to belief systems: a fact carrying a last-confirmed time, a source and a re-check interval gives a measurable per-belief bound even while the world keeps changing under it. Permanently mid-repair, and instrumented as such, is a different and better condition than permanently stale with no clock on it at all.

Most of what a model knows barely changes — arithmetic, syntax, thermodynamics. Demanding a staleness bound on an effectively static fact is rigour theatre.

This is the strongest objection and it should be granted directly. Re-checking Ohm's law nightly is waste with no epistemic return. But the argument was never for uniform re-checking; it is for typing beliefs by volatility, which is exactly what provenance makes possible — short intervals for prices and rosters, none at all for physical constants. Frozen weights cannot make this distinction because they store a 2023 exchange rate and the boiling point of water in the same undifferentiated way, with the same unwarranted confidence. Knowing where a belief came from is the prerequisite for knowing how fast it decays.

Retrieval augmentation already fixes this — bolt a search index onto a frozen model and volatile facts get fetched fresh at query time.

Retrieval is a genuine repair mechanism and it closes a large fraction of the gap cheaply. Its limit is that it is pull-only: nothing repairs a belief nobody happens to ask about, and nothing notices that a previously retrieved fact has since changed. That is read-repair without anti-entropy, and Dynamo shipped both because read-repair alone leaves cold keys arbitrarily stale. A standing subscription to an open stream is the anti-entropy half retrieval lacks. It belongs inside the continuous-intake position, not as a substitute for it.

What this does and does not establish

Eventual consistency does not prove that continuous ingestion is always worth its cost, and it does not make Large Universe Models a working system rather than an argued category. It shows something narrower and firmer: any architecture that acts on beliefs about a changing world owes an operator a statable bound on how wrong those beliefs might currently be, and that bound is only statable where the channel back to the source has been kept open. Insurance models priced off frozen hazard maps, pharmacovigilance systems waiting to be asked the right question, grid dispatch running on constraint assumptions minutes old — each owes exactly this kind of statement and mostly cannot give it. The lineage from frozen corpus to bounded scene to open stream is not a claim that later is smarter. It is a claim about which position can even be held to account for its own lag.

Continue