How to Prevent Redis Key Race Conditions: Optimistic Locks, Distributed Locks, Timestamps & Queues

Problem Description

Concurrent competition for a key means multiple clients try to set the same key at the same time.

Example Scenario 1

Multiple requests decrease inventory of a product:

Read current stock

Calculate new stock

Write new stock

Assume the current stock is 20. Two connections each try to decrement by 5. The correct final stock should be 10, but a race condition can produce an incorrect result.

Example Scenario 2

Three ordered requests modify a key. In the correct order the version sequence is 1->2->3, ending with 3. If the second request is delayed, the sequence becomes 1->3->2, ending with 2, causing an error.

Solution

1. Optimistic Lock

Optimistic locking is suitable when many clients compete for the same key and the order of modifications does not matter.

The watch command can implement an optimistic lock.

Note: This method does not work if your Redis deployment uses sharding.

The watch command monitors each specified key; when exec is called, if any watched key changed after watch, the whole transaction is aborted.

2. Distributed Lock

Suitable for distributed environments; it does not depend on whether Redis is a sharded cluster.

Acquire a distributed lock before operating on Redis; only the lock holder may perform the operation.

Common implementations include ZooKeeper and Redis itself.

3. Timestamp

Ideal for ordered‑requirement scenarios. Clients write a timestamp together with the value and only update when their timestamp is newer.

A => set key1 {a 11:01} B => set key1 {b 11:02} C => set key1 {c 11:03}

If B writes first, the key holds {b 11:02}. When A later attempts to write, it sees its timestamp 11:01 is earlier and skips the set operation.

4. Message Queue

In high‑concurrency situations, a message queue can serialize operations, providing a common solution for massive concurrent writes.

Summary

“Redis concurrent competition” occurs when many high‑frequency writes target the same key, leading to incorrect values.

Common remedies:

Optimistic lock (avoid in sharded clusters)

Distributed lock (suitable for distributed systems)

Timestamp ordering (suitable for ordered scenarios)

Message queue serialization