Preventing Race Conditions: Atomic Concurrency in Redis

Previously in this course, we covered Mastering INCR and DECR, where we learned how to use built-in commands to update numbers. In this lesson, we take that concept further: we’ll explore how to avoid race conditions by ensuring our application logic remains safe even when hundreds of requests hit our server simultaneously.

The Problem: When "Read-Modify-Write" Fails

A race condition occurs when the outcome of a process depends on the uncontrollable timing of other events. In web development, this usually happens with the "Read-Modify-Write" cycle.

Imagine you are building a system to track the number of tickets sold for an event. Your Node.js code might look like this:

JAVASCRIPT
// DON'T DO THIS
const tickets = await client.get(CE9178">'tickets_sold'); // Read
const newTotal = parseInt(tickets) + 1;           // Modify
await client.set(CE9178">'tickets_sold', newTotal);       // Write

If two users click "Buy" at the exact same millisecond, both might read 10 from Redis before either has finished the write. Both will calculate 11 and write it back, effectively "losing" one ticket sale. This is a classic concurrency bug.

Why Atomicity is Your Safety Net

An operation is atomic if it executes entirely or not at all, with no possibility of interruption by another command. Because Redis is single-threaded in its command execution, an atomic command like INCR is guaranteed to finish completely before Redis processes the next command.

By moving the "Modify" step inside the database, we eliminate the gap where other processes can interfere. We aren't just using an atomic command; we are enforcing safety by design.

Worked Example: Atomic Concurrency

To prevent the race condition in our ticket-selling scenario, we abandon the "Read-Modify-Write" pattern entirely. We use the atomic INCR command, which performs all three steps in one internal operation.

JAVASCRIPT
// DO THIS
const newTotal = await client.incr(CE9178">'tickets_sold'); 
console.log(CE9178">`Current sales: ${newTotal}`);

If you are dealing with more complex logic—like only incrementing if a limit hasn't been reached—you can't rely on INCR alone. You would typically use Redis Distributed Lock: Preventing Race Conditions in Microservices or Lua scripting (which we will cover in a later lesson) to ensure the check and the increment happen as one inseparable unit.

Hands-on Exercise

For our running project, we are building a rate limiter. Your task is to ensure that a user's request count cannot be corrupted by concurrent requests.

1. Create a function incrementRequestCount(userId) in your project.
2. Instead of fetching the count, adding 1 in JS, and setting it back, use the incr command directly.
3. Test it by firing 10 simultaneous requests to your mock endpoint (using a tool like ab or a simple Promise.all loop in a test script).
4. Verify that the final value in Redis is exactly 10, not a lower number.

Common Pitfalls

• Trusting the Application Layer: The biggest mistake is performing logic in your Node.js code (like if (count < max)) and assuming no other process will change that count while you're deciding.
• Overusing Locks: While you can prevent race conditions with manual locks (like Laravel Distributed Locks: Preventing Race Conditions with Redis), they are expensive and introduce latency. Always look for an atomic command (INCR, HINCRBY, SADD) first.
• Ignoring Network Latency: Even if your code is fast, network jitter can cause commands to arrive out of order. Relying on Redis's internal atomicity keeps your state consistent regardless of the network state.

FAQ

Q: If Redis is single-threaded, does that mean I never have race conditions? A: Redis commands are atomic, but your application logic might not be. If your code sends multiple commands, another client can sneak in between them.

Q: When should I use a distributed lock? A: Use a lock only when you need to protect a multi-step operation that cannot be expressed as a single atomic Redis command.

Q: Are there performance costs to atomicity? A: Atomic commands are the most performant way to handle state. They avoid the overhead of complex locking mechanisms.

Recap

Race conditions are the result of split-second timing collisions. By using atomic operations like INCR, we force the database to handle the state update in a single, uninterruptible step. This ensures data integrity even under heavy concurrent load.

Up next: The Fixed Window Rate Limiting Pattern, where we'll apply these atomic counters to build a functional gatekeeper for our API.