Have you ever noticed that when tickets for a popular concert, sports event, or conference go on sale, sometimes more tickets get sold than there are actual seats available?
Usually, it happens because thousands of people are trying to book at the same time.
Let’s say there’s only one seat left.
Two users click the “Buy Ticket” button almost simultaneously. The system checks whether the seat is available and tells both users “Yes, it’s available.” Before the first booking is fully completed, the second request also gets through. As a result, the same seat ends up being sold twice.
In software engineering, there’s an interesting name for this problem: TOCTOU (Time-of-Check to Time-of-Use) race condition.
The idea is simple. A system checks whether something is available, valid, or allowed, and then uses it a little later. The problem is that between the check and the actual use, another request, process, or user may change the state of the system. The original check is no longer valid, but the system continues anyway.
Ticket booking is just one example. The same issue can show up when checking whether a username is available before registration, verifying a coupon hasn’t been used before redemption, checking an account balance before withdrawal, or preventing duplicate likes on a social media post. Not only in databases, but it can happen in any file or any shared resource ‘access and update’ scenarios.
One of the most important lessons here is that checking and using a shared resource should often be treated as a single operation rather than two separate steps. That’s why databases provide things like transactions, unique constraints, and locking mechanisms—to make sure multiple requests don’t step on each other’s toes.
It’s one of those classic software engineering problems that sounds complicated, but shows up in surprisingly ordinary situations.
Have you ever encountered a TOCTOU race condition in a real project? What was the scenario, and how did you solve it?

Ahmed shamim

TOCTOU (Time-of-Check to Time-of-Use) race conditions occur when a system checks a resource's state and then uses it later, but the state changes in between. A classic example is ticket booking where two users simultaneously check seat availability and both get confirmed, resulting in double-booking. The same pattern appears in username registration, coupon redemption, balance checks, and duplicate likes. The key lesson is that checking and using a shared resource should be treated as a single atomic operation, which is why databases offer transactions, unique constraints, and locking mechanisms.

Why ticket booking systems sometimes sell the same seat twice