Preventing Race Conditions: Mastering Pessimistic Locking in Laravel

The Silent Bug in High-Traffic SaaS

As a full-stack developer building enterprise-grade B2B platforms, one of the most dangerous bugs you will encounter is the race condition. It rarely happens in local development, but the moment your platform scales and multiple users begin interacting with the same data simultaneously, the cracks appear.

Consider an inventory management system or a shared team wallet in a SaaS application. If User A and User B both attempt to deduct $50 from a wallet that only has $50 remaining at the exact same millisecond, your controller will likely read the $50 balance for both requests, approve both, and leave your database in a negative, corrupted state. In financial or industrial applications, this is catastrophic.

The Solution: Database Level Locking

Standard Eloquent updates are not enough to prevent concurrent write anomalies. We must enforce strict data integrity at the database level using Pessimistic Locking. This technique tells PostgreSQL (or MySQL) to physically lock the database row being read until the current transaction is entirely complete. Any other request attempting to read or update that same row is forced to wait in a queue.

Implementing `lockForUpdate()` in Laravel

Laravel provides an incredibly elegant wrapper for pessimistic locking using the lockForUpdate() method. However, it must be used strictly within a database transaction.

namespace App\Services;

use App\Models\TenantWallet;
use Illuminate\Support\Facades\DB;
use Exception;

class BillingService
{
    /**
     * Deduct funds safely, preventing concurrent race conditions.
     */
    public function chargeWallet(int $tenantId, float $amountToDeduct)
    {
        // 1. We MUST wrap this in a transaction. The lock releases when the transaction commits.
        return DB::transaction(function () use ($tenantId, $amountToDeduct) {
            
            // 2. Fetch the wallet AND lock the row in PostgreSQL.
            // Any other request hitting this row will PAUSE here until we finish.
            $wallet = TenantWallet::where('tenant_id', $tenantId)->lockForUpdate()->first();

            if (!$wallet) {
                throw new Exception("Wallet not found.");
            }

            // 3. Perform our business logic safely
            if ($wallet->balance < $amountToDeduct) {
                throw new Exception("Insufficient funds.");
            }

            // 4. Update the balance
            $wallet->balance -= $amountToDeduct;
            $wallet->save();

            return $wallet;

        }); // The lock is automatically released here.
    }
}

Handling Lock Timeouts

While lockForUpdate() is powerful, if a transaction takes too long (e.g., an API call to Stripe is made *inside* the lock), other requests will queue up and eventually time out, causing a bottleneck. The golden rule of pessimistic locking is to keep the transaction as incredibly fast as possible. Never put external HTTP requests or heavy processing inside a locked database transaction. Calculate the logic beforehand, lock the row, apply the update, and release.

Conclusion

When you are building software that manages money, inventory, or shared industrial assets, you cannot rely on PHP to handle concurrency. You must architect your systems to lean on the robust locking mechanisms of your database engine. Utilizing Laravel's pessimistic locking ensures your B2B SaaS maintains absolute data integrity, regardless of the traffic load.