Concept explanation
Concurrency bugs often look impossible in local testing and obvious in hindsight. This arena makes the races visible so you can practice the database move that keeps money, inventory, bookings, and jobs correct.
All games
Transaction Isolation Arena
Defend database invariants from concurrent requests by choosing transactions, locks, constraints, snapshot reads, and optimistic concurrency.
- Concept
- Database transactions, isolation anomalies, locks, and invariant protection
- Difficulty
- Advanced
- Play time
- 7-10 minutes
- Path
- Data & Performance
practice/transaction-isolation-arena Isolation design score Play, get feedback, save local progress, and optionally submit a leaderboard score.
Playable game area
Use the controls below. Feedback appears immediately, and final scores are stored locally.
Leaderboard
Top 10 submitted scores. No account required.
Loading leaderboard...
Finish the game to load your latest local score.
Learning objectives
- Identify common concurrency anomalies such as lost updates, phantoms, and partial writes.
- Choose between row locks, atomic updates, constraints, serializable isolation, and optimistic concurrency.
- Explain why application-level checks are not enough for many shared data invariants.
How to play
- Read the concurrent data scenario and identify the invariant that can break.
- Choose the database technique that protects the invariant with the least unnecessary blocking.
- Use feedback to learn which anomaly was present.
Scoring
- Correct choices add points and streak bonuses.
- Incorrect choices explain the race condition or anomaly that remains.
- Completion saves local progress and best score.
Backend concept notes
Transactions are a tool for preserving invariants across multiple reads and writes. The correct design depends on what can race: a known row, a range of rows, a multi-row transfer, or stale editor state.
Locks, constraints, serializable isolation, atomic updates, and optimistic version checks each solve different concurrency problems. Good backend engineers choose the smallest mechanism that actually protects correctness.
Common mistakes
- Checking a condition in application code and writing later without a lock or constraint.
- Using last-write-wins where users expect conflict detection.
- Assuming READ COMMITTED prevents every race.
- Adding broad table locks where row locks, constraints, or snapshots would be safer.
FAQ
Short answers for how this game fits backend interview and study practice.
Is serializable isolation always the answer?
No. Serializable is powerful but can add retries and contention. Many invariants are better protected with constraints, row locks, atomic updates, or optimistic checks.
Can queues replace database transactions?
Queues can serialize some workflows, but the database still needs to protect its own critical invariants when concurrent writers exist.