RECIPE

Leader election patterns

Coordinating distributed workers means exactly one node holds the leader lease at any time. This recipe covers three production-tested approaches Meridian customers use to elect a leader across replicas, recover quickly from failures, and avoid split-brain scenarios.

1.Lease-based election

The most common pattern: each candidate races to write a lease key with a TTL. The winner renews the lease every half-TTL; on crash, the lease expires and a new election begins. Works on Redis, etcd, ZooKeeper, and Meridian KV out of the box. Tradeoff: lease TTL sets your worst-case failover time.

2.Bully algorithm

Each node has a numeric priority. When a node detects the leader is gone, it announces an election to all higher-priority peers. If none respond, it claims leadership. Simple to reason about but chatty — O(n^2) messages worst case. Use when n is small (typically under 16 replicas).

3.Raft-style consensus

For mission-critical workloads, fold leader election into a Raft cluster. Followers promote to candidate after a randomized timeout, request votes, and become leader once a quorum acknowledges. Strong consistency, but you need an odd-numbered cluster and have to tolerate the operational weight of running a consensus group.

Lease example (TypeScript)

import { kv } from '@meridian/sdk';

const LEASE_KEY = 'jobs:leader';
const TTL_MS = 15_000;
const RENEW_MS = 5_000;

async function tryAcquire(nodeId: string) {
  const ok = await kv.setNX(LEASE_KEY, nodeId, TTL_MS);
  return ok === 'OK';
}

async function renew(nodeId: string) {
  const current = await kv.get(LEASE_KEY);
  if (current !== nodeId) return false;
  await kv.expire(LEASE_KEY, TTL_MS);
  return true;
}

setInterval(() => renew(process.env.NODE_ID!), RENEW_MS);