Database concurrency & correctness

Drag a second request's read so it lands between the first request's read and write, and watch the last token get spent twice.

Switch to UPDATE … WHERE available >= 1 RETURNING and see the same interleaving produce one success and one "zero rows" result.

See the second transaction block on a lock icon until the first commits, and compare throughput under high contention.

Watch version numbers tick up and conflicting writers retry, with a contention slider showing when retry storms make optimistic locking worse than pessimistic.

Each transaction sees the database through its own snapshot. Pick an isolation level and trigger dirty reads, non-repeatable reads, phantoms, and write skew.

Rerun the write-skew scenario (two doctors both going off call) and watch serializable isolation abort one transaction.

Two transactions lock rows in opposite order, a wait-for graph draws the cycle, and the database picks a victim to abort and retry.

Buggy application code slips past every other check, and a unique or check constraint catches it at commit time.

An in-process lock that works on one instance fails silently once you add a second instance behind the load balancer.