Pattern · seen in 3 breakdowns across 2 companies

Single-Writer Ownership

Let just one process write to each database (or shard), so that owner keeps everything it wrote in its own memory and never coordinates with other writers.

throughput

The mechanism

At its core: the usual design has many stateless servers share a database, so every write has to coordinate - locks, cache invalidation. Give each store one owner instead, and all of that collapses: it writes from its own memory with no one to coordinate with.

LIVE ARTIFACTONE WRITER, NO COORDINATIONOPEN FULL SCREEN ↗
THE IDEAThe default web-service shape is a pool of identical, stateless servers all sharing one database. Because any of them can write, every write needs coordination: a lock so two writers do not clash, and a way to invalidate everyone's caches when data changes. Single-writer ownership removes the coordination. Each store gets one owner, kept exclusive by a lease - a lock it must keep renewing to stay the writer. With no one else writing, the owner trusts its own memory completely, batches writes freely, and reads the store only to recover after a crash. The two costs: if the owner crashes, its store is unavailable until another process takes over; and if the lease ever fails and two owners write at once, the data is silently corrupted.
WHAT TO TRYStart with the shared setup and watch every write pay a coordination tax. Switch to single-writer ownership and watch that tax vanish - then crash the owner, or break the lease, and see the two costs the design accepts.

One owner per store means no locks and no cache invalidation - until the lease fails and two writers corrupt the data.

Definition

Give each store - a database, or one shard of one - a single owner: the only process allowed to write to it. Because nothing else writes, there is nothing to coordinate. The owner can hold everything it has written in its own memory and trust it completely, since no one else could have changed it. It can group and reorder writes however is fastest, and it only reads from the store to rebuild its memory after a crash. That flips the usual web-service shape, where a crowd of identical, stateless servers all share one database.

ONE OWNER PER STORE
Many servers sharing one database must coordinate; one owner per store writes from memory with no coordination.
The usual shape has many identical servers sharing one database, so every write must coordinate; single-writer ownership gives each store one owner that writes from its own memory, with nothing to coordinate.

What makes this safe is a lease: a lock that one process holds by continually renewing it, and that expires if that process stops. Whoever holds the lease is the writer; everyone else stays out. The lease usually carries a version number, so if an old owner is slow and a new one takes over, the store can reject the stale owner's writes. This lease is the whole thing's correctness: if two processes ever believe they own the same store at once, both trust their own memory and quietly corrupt the data.

This pays off for a specific shape of workload: mostly writes, over a set of data small enough to fit in one process's memory, where the cost of coordinating between writers would otherwise be the main cost. At scale the data is usually split into many shards - as in application-layer sharding - and each shard gets its own single owner. It is worth being clear how this differs from electing a leader for availability. There, replicas choose a leader so the system keeps running when a node dies. Here, the single owner exists so the writer can skip coordination, and you accept that if an owner dies, its shard is down until a successor takes the lease and reads the state back from the store.

When it applies

01The workload is mostly writes, over short-lived data. Think a deduplication store answering 'have I seen this message?', a rate limiter's counters, or a queue's in-flight jobs. A single owner keeps that hot data in memory, so almost every read is answered from memory and the store is barely touched.
02The data is split into shards, each small enough for one process. When each shard fits in one owner's memory, you can hand every shard its own single writer.
03Coordinating between writers costs more than the odd outage. If distributed locks and cache invalidation would cost more than briefly losing a shard while a successor takes over, dropping the coordination is the better trade.

Tradeoffs

Each shard has a single point of failure. If its owner crashes, that shard is stalled until a successor takes the lease and reads its state back from the store - a short outage for that shard by design.
The lease has to be exactly right. If an old owner keeps writing after its lease expired while a new one has started, the two silently corrupt the data - so the lease is not a nice-to-have, it is the correctness of the whole design.
One shard can only go as fast as one process. Since only the owner writes, a shard's throughput is capped at what one process can do, so you scale by adding more shards, not more writers per shard.

The same move, 3 ways

Every row is a production system that bet on this pattern — the note says how, in that system's own terms.

Slack
Slack Engineering
2020
In this story the pattern is restored by retiring its opposite. Slack's active-active pairs, with both sides taking writes, bought retry-through-failure availability at the cost of a nonstandard setup with no true replicas and no safe replica reads. The Vitess migration replaces those dual writers with ordinary single-primary replication per shard, and automated failovers restore the pattern's core benefit: one clear writer per slice of data, and a replica tier that can finally be trusted with reads. Read the breakdown →
Segment
Segment Blog
2018
One Director owns each database exclusively, through a Consul lock, so caching, locking, and cache-invalidation all happen inside one process with no coordination between machines. The writes stay fast because no one else can write. The lesson runs against the usual default of many identical workers over shared databases: when a workload is write-heavy with a small working set, pairing one owner to one database beats sharing. Read the breakdown →
Segment
Segment Blog
2017
The same idea Segment uses elsewhere, applied again here. Just as its Centrifuge system gives each instance sole ownership of its own jobs database, the dedupe pipeline splits the work up by message ID so that each worker's local RocksDB answers 'seen this?' for its own slice alone, with no coordination needed between workers. The ownership boundary is again what turns a global problem (search hundreds of billions of keys) into a local one (search your own partition's), and again the partition map is the quiet coordinator that makes 'coordination-free' actually true. Read the breakdown →

Problems this pattern answers

The walls where its breakdowns live — each opens the cross-company comparison.

Ambiguous failure under retrySEGMENT →Buffer degrades under backlogSEGMENT →Single-cluster scaling ceilingSLACK →