What is a race condition in a database transaction, and how does isolation prevent it?
A race condition happens when two transactions read and write overlapping data at the same time, and the final result depends on timing rather than correctness — e.g. two withdrawals both reading the same starting balance before either writes. Isolation levels define how much of that overlap is allowed; higher isolation prevents more race conditions at the cost of more locking or more retries.
Answered in
Database Transactions Explained: ACID, Isolation Levels, and Concurrency ControlWhat ACID actually guarantees, and how pessimistic vs optimistic concurrency control decide whether your app locks or retries under load.
Read the full analysisOther questions this article answers
- What does ACID actually stand for, and why do all four properties matter together?
- What's the practical difference between pessimistic and optimistic concurrency control?
- Why would a database ever allow a weaker isolation level than Serializable?
- What causes a deadlock, and how do databases resolve it?
More system design questions
- Why does a database need an index at all — why can't it just scan the table?
- When is a hash index better than a B-tree index?
- What is a composite index and why does column order matter?
- What's a covering index and why is it faster than a normal index?
- What's the real cost of adding an index, beyond disk space?
- What does ACID actually stand for, and why do all four properties matter together?
- What's the practical difference between pessimistic and optimistic concurrency control?
- Why would a database ever allow a weaker isolation level than Serializable?
Every answer on Crashtech is written by the editor of the article it comes from — never auto-summarised. Browse all answers or the System Design beat.