Meeting Room Scheduler — LLD (Overlap Detection, Booking States, Concurrency)

Meeting room scheduling looks simple until concurrency and lifecycle rules are introduced. Interviewers use it because it compresses several senior-level signals into one bounded problem: temporal modeling, invariant enforcement, and extensibility under changing business policy. If your design only handles the happy path, the interviewer can break it in two follow-ups: concurrent booking requests for the same slot and policy transitions from direct booking to approval-based workflows.

A strong answer starts by naming the core invariant: for a given room_id, no two active bookings may overlap in time. Then it maps that invariant to an atomic write boundary, not an in-memory pre-check. This is where many candidates lose points; they compute overlap correctly but still allow double-booking under race conditions because check and insert are split.

The second differentiator is lifecycle modeling. Real systems are not binary BOOKED or CANCELLED; they include tentative holds, approval states, and time-based expiry. Interviewers want to see whether you can model that state machine cleanly and guard transitions.

The third differentiator is extensibility. Teams inevitably ask for recurring meetings, capacity policies, and notification channels. Good designs add these without rewriting BookingService, using interface boundaries for policy and observer-style notifications.