Distributed Locks: Preventing Duplicate Work Across Servers

What are Distributed Locks?

Distributed locks are mechanisms that ensure only one instance of an application can perform a critical operation at a time, even when multiple instances are running across different servers.

Why Use Distributed Locks?

• Problem of Duplication: When two application servers receive the same request simultaneously, both might try to execute the same operation, leading to conflicts.
• Local Locks Limitations: Local locks (like mutexes) only work within a single process. If two servers have their own local locks, they won't coordinate with each other.

How Distributed Locks Work

1. Shared Coordination: Distributed locks use a centralized system (like Redis or ZooKeeper) to manage access to resources across multiple instances.
2. Lifecycle of a Distributed Lock:
   • Acquire: A server requests the lock.
   • Own: The server gains ownership of the lock.
   • Work: The server performs the critical operation.
   • Release: The server releases the lock after completing the work.

Handling Failures

• Lease/TTL: To prevent a lock from being held indefinitely due to a server crash, a lease or Time-To-Live (TTL) can be set. This ensures that if a server fails, the lock will eventually expire and can be acquired by another server.
• Stale Owners: If the original owner of the lock becomes slow or disconnected, it can lead to issues. This is where fencing tokens come into play, preventing the old owner from making changes after a new owner has taken control.

Key Concepts to Remember

• Distributed Lock: Coordinates ownership across multiple servers.
• Lease/TTL: Protects against abandoned locks.
• Fencing Tokens: Prevents stale owners from modifying shared resources.

Important Note

A distributed lock does not guarantee exactly-once execution. Careful design is needed to handle scenarios where the lock is released but the previous owner still attempts to perform operations.