Distributed Locks & Idempotency
ReliabilityMechanisms to ensure only one actor performs a critical action at a time, and repeated attempts don't cause duplicate side effects.
In a single process, a mutex prevents two threads from racing on shared state. Across a distributed system, you need the same guarantee (e.g. 'only one worker should process this job', 'only one node should be the cron leader') but there's no shared memory — so you use a distributed lock backed by a shared store (Redis `SETNX` + TTL, or a consensus-backed store like ZooKeeper/etcd for stronger guarantees). Idempotency is the closely related, often better, alternative: instead of preventing concurrent execution, design the operation so running it twice has the same effect as running it once (e.g. `SET status = 'shipped'` is idempotent; `balance += 10` is not).
How it connects
Distributed Locks & Idempotency as the source, with the components it typically interacts with.
- → Database Types (SQL, NoSQL & Beyond): Distributed locks are frequently used to guard critical sections around database writes (e.g. preventing two workers from double-processing the same row).
- → Consensus & Replication Protocols: Correct distributed locks are built on the same primitives as consensus (a single agreed-upon leader/lock holder), and often reuse a consensus store like ZooKeeper/etcd.
- → Message Queues & Event Streaming: Locks are used to ensure only one consumer instance processes a given message/job at a time when multiple workers read from the same queue.