Leader election vs consensus

Code side-by-side

A weak (lock-based) leader election vs. a leader election built on real consensus:

// Any node can attempt this independently
acquired = redis.set(
  "leader-lock", myNodeId,
  nx=True, ex=10  // 10s TTL
)
if acquired:
  isLeader = True
  # Risk: clock skew, GC pause, or a
  # slow network write can let the lock
  # expire while this node still thinks
  # it's the leader -> TWO leaders possible

// Kubernetes-style leader election
// (built on etcd, which runs Raft)
lease = coordination.Lease(
  name="controller-leader",
  holderIdentity=myNodeId,
  leaseDurationSeconds=15,
)
// etcd only accepts the lease renewal if
// this node's write reaches a RAFT QUORUM.
// A partitioned former leader cannot renew
// -> cannot keep believing it's safe to act

When "just do leader election" (a lock) is enough

• Low-stakes coordination. Picking which instance runs a nightly batch job — if two instances briefly both run it, the job is idempotent and safe to duplicate.
• You already depend on a single, reliable coordination store. A managed lock service (e.g. a cloud provider's distributed lock API) removes the need to reason about consensus yourself.
• Latency matters more than perfect safety. Simple TTL locks fail over faster than full consensus re-elections in some designs, at the cost of a small split-brain window.
• You can tolerate brief, bounded duplication. If "acting as leader twice for a few seconds" only costs a duplicate log line, don't over-engineer it.

When you need real consensus underneath

• The leader's actions are irreversible or high-stakes. Committing writes to a primary database, issuing payments, or promoting a replica — two leaders acting simultaneously here causes data corruption or financial loss.
• You are building the coordination layer itself. If you're writing a distributed lock service (not just using one), you need Raft or a Paxos variant underneath it, not a bare TTL.
• Regulatory or correctness guarantees are required. Systems that must prove "exactly one leader was active at any instant" for audit or compliance reasons need consensus-backed leases, not best-effort locks.
• Network partitions are common in your environment. Multi-region deployments, unreliable networks, or long GC pauses make clock-based TTL locks unsafe; quorum-based leases degrade more predictably.

English phrases engineers use

Quick decision tree

• Low-stakes, idempotent job scheduling → Simple lock-based leader election
• Leader actions are irreversible (writes, payments, promotions) → Consensus-backed leader election
• Already running Kubernetes/etcd → Use the built-in Lease API (Raft underneath)
• Building a new coordination primitive from scratch → Implement Raft, don't invent your own quorum logic
• Network partitions are rare and brief in your environment → TTL lock may be an acceptable trade-off
• Auditors or compliance require provable single-leader guarantees → Full consensus, no exceptions