Never Trust a Client, Even a Well-Behaved One
Why a user ID has to be validated server-side even though a normal frontend would never send an invalid one, and what happens the moment someone calls the API directly.
Looking up the user who's booking a ticket needs the exact same treatment already given to the show: fetch it, and throw if it isn't there.
A Real Frontend Would Never Send a Bad ID. That's Not the Point.
A normal user, going through the normal booking flow, will always arrive with a genuinely valid user ID. That's exactly the assumption an API can never afford to make. Nothing stops someone from skipping the frontend entirely and calling the API directly, with whatever values they want, including values no real user flow could ever have produced.
Picture a script looping from one to a billion, firing that same request at the API with a different, mostly-invalid user ID every time. The frontend never gets a say in that scenario at all. Whatever validation only lives in the UI simply isn't there to stop it.
Validate the Reference, Every Time, Regardless of How It Arrived
The fix is the same lookup-and-throw pattern already used for the show: fetch the user by ID, and if nothing comes back, throw immediately rather than letting a missing user quietly flow further into the method. A well-behaved caller was never the thing this check exists for. It exists for every caller that isn't one, and there's no way to tell from a single request which kind is actually asking.
Keep reading