🔒 Distributed Locking: ZooKeeper vs Redis vs Database

In modern distributed systems, multiple services often compete for shared resources — like updating a database row, writing to a file, or booking the last seat on a flight. Without coordination, this can lead to race conditions, data corruption, or duplicate work.

This is where distributed locks come in.

A distributed lock ensures that at any given moment, only one process across multiple machines can hold the lock and perform the critical operation.

🔹 Why Do We Need Distributed Locks?

Imagine an online ticket booking system with multiple servers handling requests.

• Two users try to book the last available seat.
• If both servers update the database at the same time → the seat gets oversold.

👉 A distributed lock ensures only one server books the seat while the others wait or fail gracefully.

🔹 Popular Implementations of Distributed Locks

1. ZooKeeper Locks

ZooKeeper is a distributed coordination service widely used in Hadoop, Kafka, and Hive.

How it works:

• Clients create ephemeral sequential znodes under a parent lock node (/lock).
• The client with the lowest sequence number gets the lock.
• Other clients watch the node just before them in order to avoid the "herd effect."
• If a client crashes, its ephemeral node is auto-deleted, releasing the lock.

Pros ✅

• Fairness guaranteed (FIFO order).
• Auto-cleanup on failure.
• Strong consistency (quorum-based).

Cons ❌

• More heavyweight than Redis/DB.
• Requires a ZooKeeper ensemble setup.

Example Use Cases:

• Kafka partition leader election
• Hive metastore concurrency
• HBase master election

2. Redis Locks

Redis is an in-memory key-value store that can be used for distributed locks because of its speed.

How it works:

• A client tries to set a key using:

SET resource_lock unique_id NX PX 30000

SET resource_lock unique_id NX PX 30000

• NX → only set if not exists
• PX → set expiry time (auto-release if client crashes)
• The client that succeeds holds the lock.
• To release:

DEL resource_lock

DEL resource_lock

• (but only if the value matches unique_id, to prevent deleting someone else's lock).

Redlock Algorithm: For stronger safety, lock is acquired in a majority of Redis nodes (e.g., 3 of 5) to tolerate failures.

Pros ✅

• Very fast, low latency.
• Easy to implement with libraries like Redisson.

Cons ❌

• Fairness not guaranteed.
• Redlock safety under partitions is debated.

Example Use Cases:

• Caching operations
• Short-lived critical sections in microservices

3. Database Locks

The simplest approach: use your existing relational database for locking.

Option 1: Row-Level Locks

BEGIN;
SELECT * FROM locks WHERE resource = 'seat:123' FOR UPDATE;
-- critical section
COMMIT;

BEGIN;
SELECT * FROM locks WHERE resource = 'seat:123' FOR UPDATE;
-- critical section
COMMIT;

Only one transaction can lock the row at a time.

Option 2: Insert Trick

INSERT INTO locks(resource, owner) VALUES ('seat:123', 'serviceA');

INSERT INTO locks(resource, owner) VALUES ('seat:123', 'serviceA');

• If success → lock acquired.
• If duplicate key error → lock already held.

Option 3: Advisory Locks (Postgres)

SELECT pg_try_advisory_lock(123);

SELECT pg_try_advisory_lock(123);

Pros ✅

• Strong consistency (ACID).
• No new infrastructure required.

Cons ❌

• Slower than Redis/ZooKeeper.
• Locks may remain if process crashes (needs TTL/cleanup).
• Not ideal for very high contention.

Example Use Cases:

• Systems that already rely heavily on RDBMS.
• Simple resource coordination without extra infra.

🔹 Choosing the Right Lock

• Use ZooKeeper if you need strong consistency, fairness, and coordination (e.g., leader election, metadata services).
• Use Redis if you need speed and simplicity (e.g., short-lived critical sections, cache updates).
• Use Database if you want simplicity and already have a DB, but be mindful of performance.

🔹 Final Thoughts

Distributed locks are a necessary evil in complex systems — they help maintain consistency but come with trade-offs in performance and availability.

👉 The right tool depends on your system's needs:

• ZooKeeper for correctness-first
• Redis for speed-first
• Database for simplicity-first