Backend Concurrency
Two requests, one row. Optimistic versioning, pessimistic locks, atomic operations, and the bounded-resource thinking that keeps a burst from becoming an outage.
Two requests, one row: where concurrency bugs actually live in a backend, and why they never appear in development.
Read a version, write only if it has not changed, and treat zero rows updated as a conflict — never as success.
SELECT ... FOR UPDATE serialises access to a row — and holds a lock, a connection and a transaction while you do it.
Do it in one statement the database evaluates indivisibly, instead of reading, deciding and writing from application code.
Work that starts without a limit does not fail gracefully — it consumes memory, connections and downstream capacity until something breaks.
When N concurrent requests need the same expensive result, do the work once and share it — the in-process answer to a stampede.
Every finite resource needs an explicit limit, or the system discovers its own — at the worst possible moment, in the worst possible way.