Distributed locks
Studies in this cluster, in series order. Each one keeps its own URL.
Concurrency
Locks, isolation, and the bugs that only show up in production.
Distributed locks
6 studies- 1.Distributed Locks — Correctness, Leases & Fencing TokensDistributed locks need mutual exclusion, crash safety via leases, and fencing so stale holders cannot corrupt shared state. Prefer CAS/queues when you do not need a multi-step exclusive critical section.
- 2.Redis SET NX EX vs Redlock — Single-Instance Safety & the Kleppmann DebateAtomic SET NX EX is best-effort on one Redis; Redlock’s majority story is contested (Kleppmann). Use single Redis + fencing for soft work; etcd/ZK/DB CAS for correctness-critical paths.
- 3.ZooKeeper / etcd Lock Recipes — Ephemeral Nodes, Sessions & WatchesConsensus locks use ephemeral/lease-bound keys, sequential recipes, and watches; session timeout is the fence boundary. Prefer Curator / etcd concurrency APIs over hand-rolled nodes.
- 4.Fencing Tokens — Stopping Stale Lock Holders After PartitionA monotonic fencing token must be checked by storage; without it, TTL/lease locks are unsafe after GC pauses or partitions.
- 5.Lease Renewal, Clock Skew & Heartbeat Failure ModesRenew on monotonic timers; on renew failure stop writing immediately. Clock skew and GC pauses force lease-length tradeoffs—pair renewals with fencing.
- 6.Compare-And-Swap & Optimistic Coordination — When You Do Not Need a LockConditional writes (DynamoDB, etcd Txn, Redis WATCH, Postgres version columns) beat distributed locks under low contention; watch ABA and retry storms.