Typically “pessimistic locking” with some time bound involves some kind of background task running on the backend that checks the pending reservation table, and when the reservation window expires, removes the reservation lock. You also store this expiration on the web page somewhere so the user can be notified when it expires.
The details of this approach are astonishingly tricky, and very hard to get right without race conditions and/or deadlock. Even airline reservations get this wrong sometimes and double-book seats. If you can find a tutorial or example of reservation systems, you might want to go with that as a starting point. I found quite a few resources on github, though I can’t vouch for the correctness of any of them.
“Optimistic Locking” (checking for collisions only on completion) is a fair bit simpler: you just add versions to the resource, and if the current version is higher or equal to the expected version, you bail. You don’t usually want to do this sort of thing for a booking system however, since it’s lousy UX for someone to go through the whole process only to find someone sniped their reservation while they were booking it. Still, it is an option for very low-traffic systems, especially if the booking process is fast.