What's Left for You to Implement

Every design decision behind booking a ticket has been made. Two pieces of the actual implementation were designed in full but never written, and they're worth building yourself rather than left unfinished.

Exercise One: Take the Real Database Lock

The reasoning is already fully worked out. A brief database lock has to guard the moment bookTicket checks whether every requested seat is still available, for exactly as long as that check and the following status update take, nothing longer. SERIALIZABLE isolation is the textbook mechanism for it, and holding it for the length of an entire payment flow would be a disaster at scale.

What's missing is the actual wiring: taking that lock for real around the specific lines that check and then update seat status, and confirming it actually works. Build it, then prove it: fire two requests for the same seat at the same time and confirm only one of them succeeds, the other one failing cleanly with the seat-not-available exception already designed for exactly this case.

Exercise Two: Calculate the Amount a User Actually Pays

The ticket's amount has stayed a placeholder since it was first created. Summing it up isn't the hard part: every seat's price comes from its ShowSeatType row, and adding those together for every seat in the booking is a straightforward loop.

The real exercise is the part layered on top of that sum: tax. A theatre in one city, a seat of one type, a show at one time, any of these might reasonably need a different tax treatment applied. That's exactly the shape of problem a Strategy pattern exists for: one interface for calculating tax, and a concrete implementation behind it that can change without touching anything else in bookTicket.

Build the plain sum first, prove it's correct on its own, then design the tax step as a swappable strategy sitting on top of it, not hard-coded into the same method that computes the base amount.