Why a single-writer object needs no consensus

The bakery never runs a consensus protocol, and two visitors racing for the last place in a pickup slot still get one place and one refusal. This is why that works, what it costs, and where the bakery pays.

What consensus is for

Suppose the count of places in the 10:00 pickup slot were kept on three servers, so that losing one loses nothing. Each server can take a hold. Two tabs press Place order at the same moment; one request reaches the first server and the other the third, and each sees a free place. Both say yes, and the slot is over its capacity. To stop that, the copies have to agree on one order of writes before any of them answers.

That agreement is what a consensus protocol provides. Raft keeps one log, the ordered list of every write, on several servers. One server leads: it takes every write, copies it to the others, and calls it committed once a majority holds it. The paper that set it out, In Search of an Understandable Consensus Algorithm (USENIX ATC 2014), is about making that safe whatever the network does, and the price is plain in its design: a leader to elect, a majority to reach on every write, and a minority that cannot make progress at all. The Raft Lab lets you crash its servers, split its network and watch its safety hold.

Consensus answers one question: how do several copies of the same state stay one? The bakery avoids the question by keeping one copy.

What a Durable Object is instead

A Durable Object is a named instance of a class, running on Cloudflare. As Cloudflare’s documentation describes it on 2026-11-06, there is one instance for a name in the whole world, it runs in a single location, it is single-threaded, and its storage sits with it: private to that instance, transactional and strongly consistent. Writes made with no wait between them are committed together or not at all, the runtime holds new requests back while the object’s code runs, and it holds the object’s answers back until its writes are stored.

So the bakery gives each thing that must never be double-booked an object of its own. The places in a day are the Schedule object for that sandbox and that day. An order is its own Order object, and a catering job its own CateringEvent.

What that buys

Every write to a day’s places goes through one object, one at a time, so the object itself is the order of writes, and there is nothing to agree on. When two tabs race for the last place at 10:00, both requests reach the same Schedule object. The first hold is decided and committed in one step. The second runs after it, finds the slot full, and is refused, with the next free slot named. One reservation and one refusal, with no lock service, no leader and no quorum.

The same is true of an order, so two tabs pressing the same button on the kitchen board cannot disagree about where the order is, and of a catering job, which moves one transaction at a time.

What it gives up

One copy is a choice with costs, and they are the costs consensus exists to remove.

No writes from several regions to one object. The object runs in one place, so a visitor far from it pays the round trip on every write. A bakery in one city can afford that.
Throughput bounded by one object. On 2026-11-06, Cloudflare’s limits page gave one object a soft limit of 1,000 requests a second, and its rules page put it at about 500 to 1,000 a second for simple work and fewer for heavy work. A day’s places will never come near that. One object for every visitor’s bakery would.
A stall when the instance moves or restarts. The documentation, as read on2026-11-06, says objects are shut down and restarted for code updates, for updates to the runtime and when the runtime decides where to host them, and that a request in flight that touches storage during a shutdown is stopped with an error, to keep the object unique. A consensus group keeps serving when a minority of it fails; a single object pauses until its next instance starts. The bakery’s commands carry idempotency keys, so a retry after that error is safe.
Nothing crosses two objects atomically. An object’s storage is its own, and no other object can reach it, so no transaction spans an order and its day’s places, or an order and the kitchen board.

Where the bakery pays

The last cost shapes the whole design. Because no transaction spans two objects, every object writes its events to an outbox in the same transaction as its state, and the Queue carries them to the others at least once, each subscriber skipping what it has already applied: the outbox, the Queue and the dead letters. Because a catering job touches the Schedule, Billing and Stripe over weeks, it is a saga by alarm: a chain of single-object transactions, each started by an event or a timer, and undone by steps of its own rather than a rollback. And because throughput is per object, the bakery divides by what it protects: a Schedule and a Dispatch per sandbox and day, an Order per order, and everything per sandbox, so no object carries more than one visitor’s bakery.

What the bakery does not do is replicate. If the object that holds a day’s places cannot be reached, that day’s checkout waits; it never guesses. For a made-up bakery with one kitchen that is the right trade: a few seconds of waiting, rarely, for never selling the same place twice and never running a consensus protocol to make sure.

Sources

What are Durable Objects?, Cloudflare’s documentation, read on 2026-11-06: one instance per name, single-threaded, with its own transactional, strongly consistent storage that no other object can reach.
Rules of Durable Objects, Cloudflare’s documentation, read on 2026-11-06: an object runs in a single location; input and output gates; about 500 to 1,000 requests a second for one object.
SQLite-backed Durable Object Storage, Cloudflare’s documentation, read on 2026-11-06: writes with no await between them are committed together, atomically.
Lifecycle of a Durable Object, Cloudflare’s documentation, read on 2026-11-06: why an object is shut down and restarted, and what happens to a request in flight.
Durable Objects limits, Cloudflare’s documentation, read on 2026-11-06: a soft limit of 1,000 requests a second for one object.
In Search of an Understandable Consensus Algorithm, the Raft paper, USENIX ATC 2014, read on 2026-11-06: what consensus is for: one log on several servers, a leader and a majority.
Break a Raft cluster, the Raft Lab on ihaveasegway.com, read on 2026-11-06: Raft simulated in your browser, with crashes and partitions to try.

Back to the Raft principle on How it’s built, to the decision that chose it, ADR 0003, or to the lab.