Idempotency & Concurrency Control¶

Two users (or one user's two browser tabs) editing the same row is normal. Without care, one silently overwrites the other — a lost update.

The Lost Update Problem¶

Optimistic Concurrency with a Version Column¶

Add a version (or reuse updatedAt). The client sends the version it last saw; the update only succeeds if it still matches.

1model Task {
2  // ...
3  version Int @default(0)
4}

1const result = await prisma.task.updateMany({
2  where: { id, version: clientVersion },
3  data: { ...changes, version: { increment: 1 } },
4});
5if (result.count === 0) {
6  return conflict("Task was modified by someone else"); // 409
7}

If someone changed the row first, version no longer matches, count is 0, and you return 409 Conflict instead of clobbering their work.

Idempotency Keys for Create¶

POST isn't idempotent, so a retried request can create duplicates. Let clients send an Idempotency-Key header:

Store the key with the created resource. If the same key arrives again, return the original result instead of creating a second row. This makes Create safe to retry over flaky networks.

ETags & If-Match¶

The HTTP-native version of optimistic concurrency:

Same idea, expressed in standard headers — useful for public APIs.