Defeating Race Conditions: Optimistic Locking in Laravel

The Lost Update Problem

When engineering a multi-tenant B2B SaaS platform at Smart Tech Devs, data accuracy across concurrent requests is paramount. A classic data integrity vulnerability occurs when two tenants attempt to modify the same database resource at the exact same millisecond. This is known as the **Lost Update** race condition.

Imagine Support Agent A opens an invoice to add a note. A second later, Support Agent B opens the exact same invoice to change the billing status. Agent B hits save first, updating the status. A moment later, Agent A clicks save. Because Agent A's browser was holding the older snapshot of the invoice data, their save operation overwrites the entire row, completely erasing the status update made by Agent B. Agent B's changes are permanently lost, leaving no trace in the database. To solve this, you must implement row versioning.

Pessimistic vs. Optimistic Locking

We can solve race conditions using two philosophies:

• Pessimistic Locking (lockForUpdate()): The database explicitly locks the row the moment Agent A reads it, forcing Agent B to wait in a queue. This is safe but destroys performance under high read volumes and frequently triggers database deadlocks.
• Optimistic Locking: We do not lock the row during reading. Instead, we assign a sequential version integer column to the row. When updating, we check if the version matches the snapshot we read. If it matches, we save the data and increment the version. If it doesn't match, we abort, preventing data corruption.

Step 1: The Database Migration

To implement optimistic locking, every concurrent-sensitive table must include an integer version column, defaulting to 1.

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class AddVersionToInvoicesTable extends Migration
{
    public function up(): void
    {
        Schema::table('invoices', function (Blueprint $table) {
            // Track the incremental version of the row snapshot
            $table->unsignedInteger('version')->default(1);
        });
    }
}

Step 2: Executing the Version Verification in Laravel

We bypass standard model savings and enforce a strict atomic verification update via raw database conditions or explicit transactional queries.

namespace App\Http\Controllers\Api;

use App\Http\Controllers\Controller;
use App\Models\Invoice;
use Illuminate\Http\Request;
use Illuminate\Database\Eloquent\ModelNotFoundException;

class ConcurrentInvoiceController extends Controller
{
    public function update(Request $request, string $id)
    {
        // 1. Fetch the invoice record and record its current version stamp
        $invoice = Invoice::findOrFail($id);
        $currentVersion = $invoice->version;

        // 2. Perform business logic assignments
        $invoice->amount = $request->input('amount');
        $invoice->status = $request->input('status');

        // 3. Perform an atomic check-and-set update statement
        // We only execute the update if the version in the DB is STILL equal to $currentVersion
        $updatedRows = Invoice::where('id', $id)
            ->where('version', $currentVersion)
            ->update([
                'amount' => $invoice->amount,
                'status' => $invoice->status,
                'version' => $currentVersion + 1, // Increment version atomatically
                'updated_at' => now(),
            ]);

        // 4. If zero rows were updated, someone else modified the data in the meantime!
        if ($updatedRows === 0) {
            return response()->json([
                'error' => 'Conflict detected.',
                'message' => 'This resource was updated by another user. Please refresh and try again.'
            ], 409); // Return a 409 Conflict status code
        }

        return response()->json(['success' => true, 'version' => $currentVersion + 1]);
    }
}

The Engineering ROI

Optimistic locking completely eliminates data corruption caused by concurrent updates without incurring the performance penalty of physical database-level row locks. It keeps your read paths entirely non-blocking, eliminates the possibility of transaction deadlocks, and provides clear, programmatically manageable state conflict resolution strategies for your frontend application layers.