1👍
Yes, that’s a correct use of select_for_update. You would be blocking a specific location row (apply a filter before calling select_for_update). That means that 2 different locations can be booked concurrently, but if there are 2 bookings for the same location happening at exactly the same second they would be called.
This creates a critical section and you can sure that it won’t overlap with a critical section of another request. In within the critical section, you will have to validate that the selected time slot is free – without that validation select_for_update would have no effect.
I could imagine another approach based on unique constraints, it’s not universal but might be easier to implement. Let’s imagine that you are booking a resource for a specific day. You could have a "unique together" combination for the resource_id and date. A subsequent save would raise an IntegrityError and you could catch it and inform the user that the resource was just booked for the selected date.