Single-Writer Ownership

throughput

Definition

Assign each data store exactly one writer process, enforced by a mutual-exclusion lease (a Consul session, a fencing token), so that all caching, locking, and invalidation collapse into that process's local state. With no concurrent writers there is nothing to coordinate: the owner caches everything it has written with perfect confidence, batches and orders writes freely, and touches the store on reads only during crash recovery. The pattern inverts the default web-service shape — a stateless tier sharing databases — and pays off when the workload is write-dominated with a small working set, where coordination overhead would otherwise dominate.

Boundary against leader election for availability: there, replicas elect a leader so the SYSTEM survives node loss; here, exclusivity exists so the WRITER can skip coordination entirely — availability is deliberately traded per-slice, with crash recovery reading state back from the store. The lease is correctness-critical in both, but this pattern's failure mode is quieter: a split-brain second writer corrupts cache assumptions rather than partitioning a cluster.

When it applies

  • Write-heavy stores with short-lived items, where in-process caching by a sole owner eliminates nearly all reads
  • Sharded or fleet-of-stores designs where each slice is small enough for one process to own outright
  • Systems where cross-writer coordination (distributed locks, cache invalidation) would cost more than per-slice failover time

Tradeoffs

  • Each owner is a per-slice single point of failure; a crash stalls its slice until a successor acquires the lease and re-reads state
  • The lease mechanism becomes correctness-critical — an expired-but-active writer alongside a new one is silent corruption
  • Throughput per slice is capped at one process; scaling means more slices, not more writers per slice

Seen in

  • Segment BlogMay 23, 2018

    When Queues Stop Working: Segment's Database-as-a-Queue

    One Director exclusively owns each JobDB through a Consul session, so all caching, locking, and invalidation happen in-process with zero cross-node coordination — the writes stay fast because nobody else can write. The inversion of the stateless-tier-over-shared-databases default is the lesson: when the workload is write-dominated with a small working set, exclusive pairing beats pooled access.