From Seat IDs to a Pending Ticket

TicketService.bookTicket takes a user ID, a show ID, and a list of seat IDs. Turning those three plain values into an actual booking is the same algorithm already designed earlier in this series, now written as real logic.

Turning IDs Into the Real Objects Worth Checking

The seat IDs coming in aren't enough to check anything on their own. The first real step is turning those IDs into the actual ShowSeat objects they refer to, since a status can only be checked on the real thing, not on a bare number.

With the real ShowSeat objects in hand, the next step reads their status. Two outcomes are possible from there: every seat is genuinely available, or at least one of them already isn't.

When Every Seat Is Available: Lock, Then Hand Back a Pending Ticket

If every seat checks out, lock every one of them by setting its status to locked, the exact soft-locking mechanism this series designed in detail earlier, now applied for real. Once that's done, a Ticket object gets created and returned.

Booking stops there. Paying is a separate step, not something this same method goes on to do. The method's job ends the moment a pending ticket exists and the seats are safely locked behind it — proceeding to payment from inside bookTicket would tangle two separate responsibilities into one method that should only own the first of them.

When a Seat Isn't Available: Throw, Don't Return

The other outcome is simpler to state than it might sound: if even one seat has already been taken, the method throws an exception, it doesn't return one. A failure like this is genuinely exceptional, not a normal result the caller should have to unpack from a return value — throwing makes that failure impossible to quietly ignore.