Meeting Room Booking System
Interval conflicts and atomic room allocation
Half-open intervals allow one meeting to end exactly when the next starts. Two intervals conflict when each starts before the other ends. Capacity and availability are separate filters: each selected room must hold the requested seats independently.
aStart, aEnd, bStart, bEnd := 0, 2, 2, 4
overlap := aStart < bEnd && bStart < aEnd
fmt.Println(overlap) // false: touching boundaryMulti-room allocation is one atomic decision. Collect enough qualifying rooms before reserving any, or a rejected request can block later bookings. Successful booking IDs remain reserved after cancellation to prevent accidental replay as a new reservation. Cancellation changes active schedules but keeps the lifetime registry. Return allocation order reflects the original capacity/ID selection.
Go models this service with a struct and pointer-receiver methods. Constructor functions return a pointer; validation failures return errors rather than panicking. Scalars in snapshot structs are copied by value. Maps, slices, and optional pointers still require detached copies when crossing the service boundary. Go maps do not have key iteration order; use ordered slices for ranked results. There are no threads, persistence, wall-clock reads, or external side effects in this exercise.
Put it into practice
Implement the exercise in a full-screen workspace, then run its tests.