News · New this week
Seat booking design: stop two people getting one seat
An interview-standard design for the BookMyShow double-click problem, with an atomic hold, a timer, and a database as the final guard.
Two people tap the same seat at the same moment. Who gets it? The standard interview answer is one seat, one owner, and it takes a few pieces working together. This is a common design, not BookMyShow's own system.
Why "if it looks free, book it" fails
The obvious answer is to book the seat if it shows as free. That's wrong, because both people see it as free. Each tap then looks like a valid booking, and you end up selling one seat twice.
The requirement is simple. One seat goes to exactly one person.
Make the hold a single step
The tap lands on the API server, which knows the seat map and the rules. Two taps can arrive together, so what happens next matters.
If you check the seat and then hold it as two steps, the second request can slip in between them. So the check and the hold have to be one step. That's what atomic means here. Nothing can break it in the middle.
Redis does this. It's a fast in-memory store, and the command is SET NX. It writes the hold only if the seat is free. Two requests come in, and the first one wins.
Add a timer, then take payment
The hold carries an expiry. While you pay through UPI or a card gateway, everyone else sees the seat as held. Payment is pending, and the seat is yours for now.
The timer also covers the case where you close the app halfway. The hold expires on its own and the seat goes back to the pool. No seat stays locked forever.
Write the booking in a transaction
Once payment succeeds, the booking goes into the database as one transaction. Either the whole booking is written or none of it is. If something fails midway, you don't end up with half a booking.
Why keep the database if Redis already holds the seat
A Redis hold can fail. So the database is the final guard. It has a unique rule on show plus seat, which means one show-seat can have only one booking. If a second booking somehow gets that far, the database rejects it.
The two layers do different jobs. Redis keeps people from fighting over a seat while they pay. The database makes sure a double booking can't be written even when the hold breaks.
The design in one line
The flow runs from the app to the API server, then the seat hold in Redis with SET NX and expiry, then payment, then the database with its unique show-seat rule. The hold is one step, and the booking is one transaction.
Remember the split: the atomic hold with expiry handles the race, and the database rule is the last line if the hold fails. The reel ends with a question worth arguing over with a friend. Would you hold seats in Redis or in the database?
