Stock decrements on order placement without double-counting

Stock decrement outside a database transaction is a textbook race condition: two simultaneous order requests both read stock = 1, both pass the availability check, both write stock = 0, and one physical item ships twice. CWE-362 (Concurrent Execution Using Shared Resource with Improper Synchronization) names this exact failure. At low traffic the window is small but non-zero; at peak sale traffic (Black Friday, flash sales) it becomes near-certain. ISO 25010:2011 fault-tolerance requires the system to handle concurrent requests correctly — a separate findUnique + update pattern fails this at the architecture level, not the implementation level.

Wrap the stock check and decrement in a Prisma $transaction in src/app/api/orders/route.ts so both operations execute atomically.

const order = await prisma.$transaction(async (tx) => {
  const product = await tx.product.findUnique({ where: { id: productId } })
  if (!product || product.stock < quantityOrdered) {
    throw new Error('Insufficient stock')
  }
  await tx.product.update({
    where: { id: productId },
    data: { stock: { decrement: quantityOrdered } },
  })
  return tx.order.create({ data: { productId, quantity: quantityOrdered } })
})

For high-concurrency scenarios, consider a Postgres row-level lock (SELECT FOR UPDATE) or an optimistic concurrency check (WHERE stock >= quantityOrdered in the update predicate) to further tighten the window.