Comparison
Distributed lockvsLeader election
Distributed lock
you need only one instance across the whole fleet to run the job, so they all try to claim a key in Redis first.
Mutual exclusion coordinated through an external store shared by multiple processes. It is far weaker than an in-process lock: the holder can be paused, partitioned or garbage-collected while its lease expires, and it will not know. Safe use needs a lease plus a fencing token checked by the resource itself.
Full entry →Leader election
you need exactly one instance to run the nightly job, so the instances have to agree among themselves who it is.
Choosing a single coordinator among peers, typically via a consensus store with leases. It is how you get singleton behaviour out of a horizontally scaled deployment. Elections are not instantaneous or unambiguous, so any leader-only work must also be safe to run twice, briefly, during handover.
Full entry →