Leader election

Choosing one node to coordinate work, such as accepting writes or running a scheduled job. It relies on consensus and leases so that a new leader is chosen when the old one stops responding.

Where it shows up in real systems

  • Scheduler

    Use it for nightly reports, cleanups and retries. A single scheduler is a single point of failure; managed schedulers or leader election avoid running the same job twice.

    In production: Amazon EventBridge Scheduler, Kubernetes CronJob, Celery beat, cron

  • Document database

    A replica set elects a new primary when the current one fails. With write concern majority, an acknowledged write survives that failover; with w:1, recent writes can be rolled back. Reading from secondaries scales reads but returns slightly stale data.

    In production: MongoDB Atlas, Amazon DocumentDB, Couchbase, Firestore

  • Coordination service

    Runs Raft or ZAB on an odd number of nodes: three nodes survive one failure, five survive two. Use it for small, critical data, never as a general database.

    In production: etcd, Apache ZooKeeper, Consul KV

See it break, then fix it

Build an architecture, send it a day of traffic and outages, and learn why it holds or fails. Free to start.