Navigating Next.js Server Actions: Handling Race Conditions and Optimistic UI

Next.js Server Actions have simplified full-stack development by removing the need to write separate API endpoint controllers. However, because Server Actions run as independent serverless functions, they introduce concurrency risks. If multiple updates are submitted concurrently, database race conditions can occur.

Understanding Concurrency in Serverless Environments

Consider an inventory management interface where users can reserve inventory items. If two users click "Reserve" at the same time, the server action reads the current database count, checks if space is available, and writes the incremented value back. Because these operations are non-atomic, both actions might read the same count simultaneously, resulting in double reservations.

Solving these issues requires combining front-end state management with backend database transactions. We implement these patterns daily across our software engineering projects to ensure data integrity.

Front-end: Implementing Optimistic UI

To prevent user interfaces from feeling slow, we use React's useOptimistic hook. This hook displays the expected result of a server action instantly, reverting to the original state if the server operation fails.

import { useOptimistic, startTransition } from 'react';

export function ReserveButton({ initialCount }) { 
  const [count, setOptimisticCount] = useOptimistic(
    initialCount,
    (state, amount) => state + amount
  );

  const handleReserve = async () => {
    startTransition(async () => {
      setOptimisticCount(1);
      try {
        await executeReservationAction();
      } catch (err) {
        console.error('Reservation failed, rolling back.');
      }
    });
  };

  return <button onClick={handleReserve}>Reserved: {count}</button>;
}

Backend: Atomic Transactions and Row Locking

On the server, optimistic UI is not enough. We must guarantee that database updates are atomic. In PostgreSQL, this is achieved using SELECT ... FOR UPDATE to lock the target rows until the transaction completes, preventing other processes from modifying them.

// Example Prisma Transaction with Row Locking
await prisma.$transaction(async (tx) => {
  // Lock the inventory row for update
  const item = await tx.$queryRaw`
    SELECT * FROM "Inventory" 
    WHERE id = ${itemId} 
    FOR UPDATE
  `;

  if (item[0].available <= 0) {
    throw new Error("Inventory exhausted");
  }

  await tx.inventory.update({
    where: { id: itemId },
    data: { available: { decrement: 1 } }
  });
});

Optimistic vs Pessimistic Concurrency Control

Developers must choose the correct concurrency strategy based on write volume:

• Optimistic Concurrency Control (OCC): Assumes conflicts are rare. Each record has a version number. When updating, the app checks if the version has changed since it last read the record. If it has, the update is rejected and the user must retry. OCC is highly efficient for read-heavy systems.
• Pessimistic Concurrency Control (PCC): Assumes conflicts are common. It uses database locks to block other transactions from reading or writing target rows until the active transaction completes. PCC is necessary for inventory systems and payment gateways.

A Concurrency Control Comparison

To visualize the transactional difference between OCC and PCC, consider this workflow comparison:

Optimistic Concurrency Control:
[Read Row (Version 1)] ──► [Modify Data] ──► [Write Row IF Version is Still 1] (Succeeds)
[Read Row (Version 1)] ──► [Modify Data] ──► [Write Row IF Version is Still 1] (Fails - Retry)

Pessimistic Concurrency Control:
[Read Row & Lock FOR UPDATE] ──► [Block Other Access] ──► [Modify & Write] ──► [Release Lock]

Key Recommendations for Next.js

To build secure Server Actions, implement these key design patterns:

• Input Validation: Always validate Server Action inputs using a schema validation library like Zod on the server side to prevent malicious inputs.
• Error Boundaries: Ensure exceptions thrown in actions are caught and displayed via UI error boundaries instead of crashing the client runtime.
• Idempotency Keys: Pass unique keys with each action to identify and block duplicate submissions resulting from double-clicks.