Why Checkout Has Two Steps, and You Only Get Ten Seats

That's the layout problem solved. The second engineering problem this case study exists to teach is a different kind of hard: two people can look at the exact same available seat, at the exact same instant, and only one of them can walk away with it.

The Problem: Two People, One Seat, Same Instant

Start with the basics. A seat has an ID, a name, and a status: available, or booked.

Now picture two people, both looking at seat one, both clicking book at the same moment. BookMyShow cannot let both of them succeed. Exactly one booking has to go through.

That's easy to state and surprisingly tricky to guarantee. The actual mechanism for it comes later. First, there's a simpler question worth separating out.

Selecting Is Free. Booking Is Not.

Can two people select the same seat at the same time? Yes, no problem there. Selecting a seat doesn't commit anything.

Can two people book the same seat? No, that can never happen. Booking is the moment that has to be exclusive.

That distinction is the whole reason checkout works the way it does on every site you've ever used.

Why Every Checkout Has Two Steps

Think about Flipkart, Amazon, MakeMyTrip, or BookMyShow. None of them let you select an item and pay for it on the same page. You pick a product, then click through to a separate step before payment even appears.

On Flipkart, clicking "place order" takes you to an address screen first, then an order summary, and only then to payment. Amazon does the same thing: "proceed to buy," then an address, then payment. Every site inserts the same pause in the same place.

That pause isn't a UX accident.

ExpandSelecting a seat is free for anyone, but the moment checkout moves to payment, that seat gets reserved and everyone else is blocked out

The Moment You Click "Continue to Pay," the Seat Gets Reserved

Here's what that second step actually does: it reserves the item. The moment you move from selecting to paying, the system marks that item as claimed, so nobody else can take it while you're mid-checkout.

For a physical product, that might mean the available quantity drops by one. For a movie seat, it means the seat's status changes to something other than available, so anyone else looking at the seating chart won't be offered it.

This explains something you may have noticed without knowing why. Two people pick seats on the same layout, one of them moves to payment, and the other person's screen suddenly shows those seats as unavailable, even though no booking has actually happened yet.

Nobody booked the seat. Someone just started the process of booking it, and that was enough to lock everyone else out.

A Reservation Can't Last Forever

Here's the obvious follow-up question: should that reservation hold indefinitely, until the payment actually finishes?

No, and the reason is abuse. If a reservation never expired, someone could add an item to their cart, move to payment, and simply never pay, locking it forever and costing the platform that sale.

That's why checkout flows carry a timeout, usually five to fifteen minutes. Miss it, and the reservation releases, the item goes back to available, and someone else gets a fair shot at it.

The Real Reason You Can Only Select Ten Seats

This same abuse risk explains a smaller mystery: why does a platform like MakeMyTrip cap how many seats you can select at once, instead of letting you grab every seat in the house?

Picture what happens without that cap. One person selects every seat in a show, moves to the payment page, then does nothing. For the entire timeout, that show shows up as completely sold out, even though not one ticket sold, and everyone else who wanted it is locked out for no reason.

Capping selection at ten seats limits how much damage one abandoned checkout can do. A product rule that looks arbitrary from the outside is actually a direct consequence of the concurrency problem underneath it. The timeout and the seat cap exist because two people can't be allowed to book the same seat, not the other way around.

With the shape of the problem clear, seats need actual locking, not just a UX pattern borrowed from e-commerce. That's the part that happens entirely on the backend, and it's next.