# Overview of Distributed Locks #flashcard - A distributed lock is a system component that can be used to lock a portion of a system for a reasonable period of time. The locked component is often a data entity that may be in the process of being updated, so it is locked to prevent any conflicts (i.e., holding a ticket that might be booked in a ticketing application). - They are often implemented using a key-value store, such as [[Redis]] or [[Apache ZooKeeper]]. The key associated with data to be locked can be set to `key:locked` when processing is initiated. If any other part of the system tries to touch this data it will see it is locked. Once processing concludes, the database can be updated to `key:unlocked`. Moreover, a [[TTL]] value can be applied to the lock, so that if it is never updated back to `unlocked`, the original lock can naturally expire. <!--ID: 1751507776447--> ## General Use Cases - E-commerce Checkout Systems - Distributed [[cron]] jobs # Key Considerations ## Locking Mechanisms and Configurations | Approach | Database | Description | Pros | Cons | Use Cases | | ----------- | -------- | ----------- | ---- | ---- | --------- | | [[Redlock]] | | | | | | **Lock Expiry** **Lock Granularity** ## Deadlocks #flashcard Deadlocks can occur when two or more processes are waiting for each other to release a lock. Think about a situation where two processes are trying to acquire two locks at the same time. One process acquires lock A and then tries to acquire lock B, while the other process acquires lock B and then tries to acquire lock A. This can lead to a situation where both processes are waiting for each other to release a lock, causing a deadlock. You should be prepared to discuss how to prevent this. <!--ID: 1751507776449--> # Implementation Details # Useful Links # Related Topics ## Reference #### Working Notes #### Sources - [Key Technologies for System Design in a Hurry](https://www.hellointerview.com/learn/system-design/in-a-hurry/key-technologies#distributed-lock)