Prevent Race Conditions in Laravel

What Are Race Conditions?

A race condition is when the action of a program depends on the timing or sequence of random events. In web applications, this typically happens when multiple concurrent requests attempt to read and update a shared data at the same time.

Think about this scenario: two customers at once try to purchase the last item in inventory. Both orders show that there is 1 item available, both purchase and move ahead, and oops, you’ve sold 2 items when you only had 1 in inventory.

Common Race Condition Scenarios in Laravel

1. Inventory Management

// Vulnerable to race conditions
public function purchaseItem(Request $request)
{
    $product = Product::find($request->product_id);
    
    if ($product->stock > 0) {
        // Race condition can occur here!
        $product->stock -= $request->quantity;
        $product->save();
        
        // Create order
        Order::create([
            'product_id' => $product->id,
            'quantity' => $request->quantity,
            'user_id' => auth()->id()
        ]);
    }
}

2. Account Balance Updates

// Vulnerable to race conditions
public function withdraw(Request $request)
{
    $account = Account::find(auth()->user()->account_id);
    
    if ($account->balance >= $request->amount) {
        // Race condition can occur here!
        $account->balance -= $request->amount;
        $account->save();
        
        Transaction::create([
            'account_id' => $account->id,
            'amount' => -$request->amount,
            'type' => 'withdrawal'
        ]);
    }
}

How Negative Balance Could Occur

Scenario:

• Initial balance: $100
• User A tries to withdraw $80
• User B tries to withdraw $60
• Both requests arrive nearly simultaneously

Consequences

1. Negative balance: Account ends up at -$40 when it should have been rejected
2. Double spending: $140 was withdrawn from a $100 account
3. Financial loss: The bank loses money it didn’t have

3. Counter Increments

// Vulnerable to race conditions
public function incrementViews(Post $post)
{
    $post->views = $post->views + 1;
    $post->save();
}

Prevention Strategies

1. Database Transactions with Locking

Laravel provides several locking mechanisms to prevent race conditions:

Pessimistic Locking (SELECT FOR UPDATE)

Applies an exclusive lock to prevent concurrent modifications, ensuring data integrity during high-traffic operations.

// Safe with pessimistic locking
public function purchaseItem(Request $request)
{
    return DB::transaction(function () use ($request) {
        // Wraps all operations in a transaction (all succeed or all fail)
        $product = Product::where('id', $request->product_id)
            ->lockForUpdate() // lockForUpdate() to block concurrent access
            ->first();
        
        if ($product->stock >= $request->quantity) {
            $product->stock -= $request->quantity;
            $product->save();
            
            return Order::create([
                'product_id' => $product->id,
                'quantity' => $request->quantity,
                'user_id' => auth()->id()
            ]);
        }
        
        throw new Exception('Insufficient stock');
    });
}

Optimistic Locking (Version Control)

Implements version control at the data layer, ensuring update conflicts are detected before write operations complete.

First, add a version column to your table:

Schema::table('products', function (Blueprint $table) {
    $table->integer('version')->default(0);
});

Then implement optimistic locking:

// Safe with optimistic locking
public function purchaseItem(Request $request)
{
    $maxRetries = 3;
    $attempts = 0;
    
    while ($attempts < $maxRetries) {
        try {
            return DB::transaction(function () use ($request) {
                $product = Product::find($request->product_id);
                $originalVersion = $product->version;
                
                if ($product->stock >= $request->quantity) {
                    $affected = Product::where('id', $product->id)
                        ->where('version', $originalVersion)
                        ->update([
                            'stock' => $product->stock - $request->quantity,
                            'version' => $originalVersion + 1
                        ]);
                    
                    if (!$affected) {
                        throw new Exception('Concurrent modification detected');
                    }
                    
                    return Order::create([
                        'product_id' => $product->id,
                        'quantity' => $request->quantity,
                        'user_id' => auth()->id()
                    ]);
                }
                
                throw new Exception('Insufficient stock');
            });
        } catch (Exception $e) {
            $attempts++;
            if ($attempts >= $maxRetries) {
                throw $e;
            }
            usleep(100000); // Wait 100ms before retry
        }
    }
}

2. Atomic Operations

Laravel’s decrement() method executes an atomic database operation, preventing race conditions without additional locking.

// Atomic decrement
public function purchaseItem(Request $request)
{
    return DB::transaction(function () use ($request) {
        $affected = Product::where('id', $request->product_id)
            ->where('stock', '>=', $request->quantity)
            ->decrement('stock', $request->quantity);
            // The operation is handled directly in the database
        
        if ($affected === 0) {
            throw new Exception('Insufficient stock');
        }
        
        return Order::create([
            'product_id' => $request->product_id,
            'quantity' => $request->quantity,
            'user_id' => auth()->id()
        ]);
    });
}

3. Queue-Based Processing

For non-critical operations, use queues to serialize processing:

// ✅ Queue-based processing
public function incrementViews(Post $post)
{
    IncrementViewsJob::dispatch($post->id);
}

// Job class
class IncrementViewsJob implements ShouldQueue
{
    public function __construct(private int $postId) {}

    public function handle()
    {
        Post::where('id', $this->postId)
            ->increment('views');
    }
}

4. Using Cache Locks

Use Laravel’s Cache:lock() to ensure that only one process executes a critical section of logic at a time, preventing race conditions or duplicate operations.

use Illuminate\Support\Facades\Cache;

// Cache-based locking
public function purchaseItem(Request $request)
{
    // Lock for 30 seconds
    $lock = Cache::lock("product_purchase:{$request->product_id}", 30);
    
    if ($lock->get()) {
        try {
            return DB::transaction(function () use ($request) {
                $product = Product::find($request->product_id);
                
                if ($product->stock >= $request->quantity) {
                    $product->stock -= $request->quantity;
                    $product->save();
                    
                    return Order::create([
                        'product_id' => $product->id,
                        'quantity' => $request->quantity,
                        'user_id' => auth()->id()
                    ]);
                }
                
                throw new Exception('Insufficient stock');
            });
        } finally {
            $lock->release();
        }
    }
    
    throw new Exception('Unable to process request');
}

Prevents race conditions across processes using cache-based locking.

Best Practices

• Identify Critical Sections: Look for read-modify-write operations in your code
• Use Appropriate Locking: Choose between pessimistic and optimistic locking based on your use case
• Keep Transactions Short: Minimize lock duration to improve performance
• Handle Deadlocks: Always implement proper error handling and retry mechanisms
• Monitor Performance: Track lock contention and transaction times
• Use Atomic Operations: Prefer database-level atomic operations when possible
• Consider Eventual Consistency: For non-critical operations, eventual consistency might be acceptable

Conclusion

Race conditions in Laravel applications can lead to serious data integrity issues, but they’re preventable with the right strategies. Choose the appropriate technique based on your specific use case, performance requirements, and system architecture.

By following these patterns and best practices, you can build robust Laravel applications that handle concurrent requests safely and efficiently.

If you found this helpful, feel free to share or drop a comment. Happy coding with Laravel! 🧱✨