Skip to content

PATTERN Cited by 2 sources

Prefer lock-based over lock-free consensus at scale

What it is

A scale-driven architectural recommendation from Sugu Sougoumarane's Consensus algorithms at scale series: for large-scale production consensus systems, prefer lock-based leader election ("first elector wins" via an exclusive lock) over lock-free leader election ("newest elector wins" via time-ordered proposal numbers).

Sugu introduces the taxonomy in Part 5 and the recommendation in Part 5 (short form) + Part 8 (long form with four-reason justification):

"In general, a lock-free approach (like what Paxos uses) has elegance from the fact that it does not have a time component. However, lock-based approaches offer so many other flexibilities that they win out in real-life scenarios." (Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-8-closing-thoughts)

"Due to all these advantages, most large-scale systems implement a lock-based approach."

The four advantages, enumerated

From Part 8:

"With lock-based approaches, you can: (1) Perform graceful leadership changes by requesting the current leader to step down. (2) Although I didn't cover this topic, it is easier to add or remove nodes in a system. (3) You can perform consistent reads by redirecting the read to the current leader. (4) You can implement anti-flapping rules."

1. Graceful leadership changes

A stable leader identity lets an external coordinator (the elector) ask the current leader to step down cleanly — drain in-flight requests, signal successor, flush buffers — before the transition starts. Lock-free systems have no stable published leader; every follower's view of "who is leader" can lag, and graceful demotion has no natural protocol hook.

Canonical wiki instance: patterns/graceful-leader-demotion in Vitess PRS (PlannedReparentShard) uses vttablet lameduck + vtgate query buffering to deliver "no errors to the application" during software-deploy failovers. This would be structurally impossible in a Paxos-style lock-free substrate.

2. Easier node addition / removal

Adding or removing a cluster node is a membership change that must be coordinated against every in-flight consensus round. Lock-based systems serialise membership changes through the lock: acquire lock → update membership → release lock. Lock-free systems need a separate sub-protocol (Raft's joint consensus, Paxos's reconfiguration) that is notoriously subtle and often implemented incorrectly.

Sugu explicitly notes this is "not covered" in the series but flagged as an advantage.

3. Consistent reads by direct-to-leader routing

With a stable leader identity (and a leader lease on top), any read can be routed directly to the current leader and served from its local state — no quorum read, no cross-node coordination, no extra round-trip. The lease gives the leader proof-of-no-concurrent-leader for the lease window.

Lock-free systems have no stable leader → every read must either (a) go through the full consensus round (expensive), (b) accept stale reads (consistency-weakening), or (c) implement a quorum-read protocol (extra network hops + latency). The cost difference at scale is structural.

4. Anti-flapping rules

A stable leader + a lock gives the system a natural place to enforce "don't change leaders more often than N seconds" — the lock-holder can implement the rate-limit directly. Anti-flapping is Sugu's capstone-named primary failure-loop-avoidance mechanism AND (serendipitously) the mitigation for the seven propagation failure modes from Part 7.

Lock-free systems can implement anti-flapping but the rate-limit has no natural enforcer — every elector has to check a wall-clock and self-limit, which is easy to violate under clock skew or partition.

The lock-free counter-argument (which the pattern rejects)

Sugu names the lock-free advantage honestly: "a lock-free approach (like what Paxos uses) has elegance from the fact that it does not have a time component." No clocks, no leases, no timeout tuning. The protocol is correct under arbitrary scheduling.

The pattern rejects this counter-argument on operational grounds: the four advantages above all depend on having a time component anyway (step-down coordination, membership-change coordination, lease-backed reads, anti-flapping rate-limits). A production system that wants cheap consistent reads + graceful failover + anti-flapping cannot be time-component-free in practice — so giving up lock-free's elegance buys you features you'd otherwise have to bolt on.

Canonical production instances

  • Vitess + VTOrc — VTOrc uses etcd to hold the leadership lock (patterns/external-coordinator-for-leadership-lock). All four advantages are instantiated: graceful demotion via PlannedReparentShard, node membership via AddTablet / RemoveTablet, direct-to-leader reads, anti-flapping inherited from Orchestrator.
  • MySQL + Orchestrator — the pre-Vitess generation of the same pattern; anti-flapping is what "has allowed organizations to avoid split-brain scenarios while running MySQL at a massive scale" per Sugu's Part 7.
  • Raft (used as lock-based) — Raft is lock-free at the protocol layer (term numbers) but in practice used as a lock-based substrate because elections are rare and leaders are long-lived. The four advantages are built on top of Raft's stable-leader property even though Raft itself doesn't name "lock."

Counter-examples

  • Multi-Paxos at cloud scale (Google Chubby, Spanner's Paxos groups) — uses leader-holds-lease-over-multi-Paxos-rounds to get the four advantages anyway, essentially reconstructing lock-based on top of a lock-free substrate. The pattern's claim is that if you're going to reconstruct lock-based anyway, start lock-based.
  • Classic Paxos / single-decree Paxos — genuinely lock-free; no stable leader. Used in practice only for narrow cases (Cassandra's lightweight transactions, Zookeeper's leader election inside a larger system). Not suitable as a general-purpose large-scale consensus substrate for these four reasons.

Composes with

When to choose lock-free instead

  • Very small cluster (3–5 nodes) where lease management is more overhead than the protocol it saves.
  • Genuinely one-shot decisions (DNS updates, SSL certificate distribution) where no stable-leader value exists to be preserved.
  • Environments without a reliable external coordinator (no etcd, no ZooKeeper) and unwilling to take on majority-quorum lock mechanics.

Sugu's position: these cases exist, but they are not the large-scale production case. For databases, control planes, distributed storage, and other sustained-consensus workloads, lock-based wins.

Seen in

Last updated · 347 distilled / 1,201 read