The Double Booking That Only Happens At Nine In The Morning
Decide what you would do from the brief alone, including whether you would change anything at all. Everything below it is available, but the exercise stops working if you open it first.
A clinician is occasionally booked into two overlapping appointments. The code reads the clinician's appointments, checks for a conflict, and refuses if it finds one. It is correct on one instance, and the service runs four.
Wrapping the check and the insert in a transaction. It reads like the fix, it is a one-line change, and the race genuinely narrows — which is why it survives review by people who know what a transaction is. At the default isolation level of most databases a plain read does not block another transaction's insert, so both requests still see a free slot and both commit. The narrowed window is worse than the original in one specific respect: double bookings become rare enough to look like front-desk error, so the next three months of investigation go to training the receptionists. Atomicity is not mutual exclusion, and this invariant needs the second one.
Read this even if you are confident. It is here rather than behind a button because it is the answer most teams actually ship, it passes review, and the cost of it does not arrive until the change after this one.