Beyond if (stock > 0): Handling Race Conditions in High-Traffic E-Commerce Systems

Why basic logic fails at scale and how to implement Optimistic Concurrency Control in Node.js & MongoDB.

In the early stages of building an e-commerce application, inventory management seems straightforward. Logic dictates: check if the item is in stock, and if it is, process the order and decrement the count.

It usually looks something like this:

// The Naive Approach
const product = await Product.findById(productId);

if (product.stock > 0) {
  product.stock -= 1;
  await product.save();
  // Process payment...
} else {
  throw new Error('Out of stock');
} 

In a development environment, this works perfectly. In a production environment with concurrent users, this is a disaster waiting to happen.

The Problem: The Race Condition Imagine two users, Alice and Bob, try to buy the last iPhone at the exact same millisecond.

Thread A (Alice) reads the DB: Stock = 1.

Thread B (Bob) reads the DB: Stock = 1.

Thread A passes the if check and decrements stock to 0.

Thread B also passes the if check (because it read the stale data before Thread A finished) and decrements stock to -1.

We have now sold two phones when we only had one. This leads to customer support nightmares and reconciliation issues.

The Experienced Solution: Atomic Operations To solve this without locking the entire database (which kills performance), we leverage the atomicity of the database engine itself. Instead of a "Read-Modify-Write" pattern in the application layer, we push the logic to the database layer.

In MongoDB (Mongoose), we can use findOneAndUpdate with a query filter that acts as our guard:

JavaScript

// The Scalable Approach
const updatedProduct = await Product.findOneAndUpdate(
  { 
    _id: productId, 
    stock: { $gt: 0 } // The Atomic Guard
  },
  { 
    $inc: { stock: -1 } // The Atomic Update
  }, 
  { new: true }
);

if (!updatedProduct) {
throw new Error('Out of stock or race condition detected');
}
Why this works: The database process is linear. Even if two requests hit the database simultaneously, MongoDB will process one first. The first request matches the document because stock > 0. It decrements the stock. The second request immediately fails to match because stock is now 0.

Conclusion Building for scale requires moving beyond happy-path logic. By utilizing atomic database operations, we ensure data consistency without the overhead of pessimistic locking or queues, ensuring our application remains robust even during flash sales.