Requesting process
Cloud / Knowledge library
Distributed Lock
Coordinates exclusive access across networked processes
Why learn Distributed Lock?
It protects operations that cannot safely run concurrently
The problem it solves
It prevents conflicting actors from modifying one shared resource
Where it came from
Distributed Lock is a distributed systems concept that coordinates exclusive access across networked processes. Its guarantees and tradeoffs depend on the concrete implementation and operating context.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Define Distributed Lock and distinguish it from a neighboring concept.
- Choose a realistic task where Distributed Lock is appropriate.
- Identify a failure mode caused by misusing Distributed Lock.
- Interpret a small design or result involving Distributed Lock.
- Explain one tradeoff or limitation of Distributed Lock.
Documentation and sources
- Designing Data-Intensive Applications (dataintensive.net)
Connect the ideas
Explore next
Real World Example
Automated Inventory Reservation System
Global e-commerce platforms managing high-velocity inventory across multiple regional data centers.
The business problem
When two independent service instances attempt to reserve the last remaining unit of a high-demand product simultaneously, a race condition occurs. Without coordination, both instances may confirm the reservation, leading to overselling and inventory discrepancies that require manual reconciliation.
How this topic solves it
A distributed lock provides a mechanism to ensure mutual exclusion across networked processes. By requiring a service to acquire a lease on a specific resource key before modifying inventory state, the system forces sequential access. Only one process can hold the lock at any given time, effectively serializing the reservation logic and preventing conflicting updates.
- Define a unique resource identifier for the specific inventory item.
- Attempt to acquire a distributed lock from a centralized coordination service using the resource ID.
- Verify lock acquisition success; if failed, retry or reject the request.
- Execute the inventory decrement operation within the protected critical section.
- Release the lock immediately after the transaction completes to allow other processes to proceed.
This diagram illustrates the interaction between service instances and the lock coordinator.
Concurrent process
Centralized state store
Shared data store
- Service Instance A → Acquire Lock → Lock Coordinator
- Lock Coordinator → Grant Access → Service Instance A
- Service Instance A → Update Inventory → Inventory DB
- Service Instance B → Request Lock (Blocked) → Lock Coordinator
Expected business outcome
The system achieves consistent inventory states where overselling is programmatically prevented, ensuring that each unit is reserved by exactly one customer process.
Limitations and checks
A primary limitation is the risk of a deadlocked resource if a process crashes while holding the lock. To check for this, monitor the lock lease duration and ensure the coordination service supports automatic expiration or TTL-based cleanup to prevent permanent resource unavailability.