Why might a transaction alone not be enough to protect a limit?
Answer out loud or in your head first, then compare.
Answer
Two requests can both read that one spot is left and then both try to take it. Wrapping a few statements in a transaction doesn't mean every such race is resolved the way we intend. What matters is how the write is done and the isolation level, i.e. the rules for seeing concurrent changes.
For a simple limit, a single conditional write is useful: increase the counter only if it's still below the limit. For more complex changes you can use suitable locks or higher isolation and handle the need to retry the whole transaction. And I don't wait for a long LLM result while holding database resources.
Why it matters: A concrete answer to a concurrent-access problem, after learning about transactions.
Possible follow-ups: What do you do when the database rejects a transaction because of a conflict?
How did it go? Be honest — “Not yet” puts the question on your review list.
Start with
- D-P14 · Why can a message from a queue arrive a second time? — Backend, data and system design
- D-P15 · What is idempotency? — Backend, data and system design
Related questions
Further reading
- PostgreSQL: Transaction Isolation(opens in a new tab)Docs; accessed 22.10.2026. Isolation, locks and serialization anomalies; a good basis for working with an ORM.
- Drizzle ORM: Transactions(opens in a new tab)Docs; accessed 22.10.2026. Transactions, rollback and using tx.