/System Design /Distributed Locks ← All Designs
🔒

Distributed Locks

Coordinate shared resource access across multiple servers

Coordination Concurrency
🎮 What you can do
  • Set how many services compete (2–5)
  • Choose lock TTL and algorithm (Single Redis / Redlock)
  • Click Crash Holder to kill the lock owner mid-operation
👁 What to watch
  • TTL countdown bar pulses red as it approaches zero
  • After a crash the lock drains then transfers to the next waiter
  • Redlock shows quorum negotiation across 5 Redis nodes
Services Competing
Lock TTL
Algorithm
Rate
Controls
0
Acquisitions
0%
Contention
0ms
Avg Wait
0
TTL Expirations
Single Redis
SET key value NX PX ttl

Simple and fast. Single point of failure — if Redis crashes, the lock is gone. Perfect for most use cases where Redis HA (Sentinel/Cluster) is in place.
Services
Shared Resource
🔓
FREE
—
TTL: —
Grants: 0
Lock Info
Switch to Redlock to see multi-node quorum acquisition in action.
Activity Log
Simulation not started...
When to Use
Distributed cron jobs, inventory reservation, leader election, preventing double-spend, rate limiting across pods.
Trade-offs
TTL too short = race condition; too long = stuck lock. GC pauses can cause a holder to exceed its TTL invisibly.
Interview Tip
Always ask: what if the holder crashes? TTL is the answer — but clock drift can still cause issues (Martin Kleppmann's Redlock critique).