Problem statement
Design the object model and public APIs for the booking core of an office meeting-room scheduler: the class graph that owns rooms, bookings over time intervals, and the rules that decide whether a requested slot can be granted without clashing with anything already on the calendar.
Operating context. One building, roughly 20-80 rooms, each with a capacity and a set of amenities (projector, video-conf unit, whiteboard, standing desks). An employee asks to book a room for a half-open time interval [start, end) on a given day; the system must reject the request if it overlaps any existing booking for that room. Bookings may be one-off or recurring (e.g. every weekday at 10:00 for six weeks); a recurring series can be cancelled whole or one occurrence at a time. Employees also ask the reverse question: 'find me any room that seats 8, has a projector, and is free 14:00-15:00 tomorrow.' Assume a single in-process service driving an in-memory model on one thread per request, with a shared calendar many requests read and mutate.
Out of scope. Persistence and the database schema, the calendar-invite / email notification layer, authentication and per-user permissions, the HTTP/REST surface, timezone and daylight-saving conversion (assume one fixed building timezone), and any UI. Focus on the in-process object model, not the wire or storage layers.
What to produce. The class hierarchy (entities, value objects, and the services that own conflict detection and the free-slot search), the public method signatures each class exposes, and the state transitions of a booking (requested -> confirmed -> cancelled, plus per-occurrence overrides on a series). Be explicit about: how you represent a time interval and detect overlap between two of them; how a recurring series expands into occurrences without materializing an unbounded list; how 'find an available room' filters by capacity and amenities and then by free time; how cancelling one occurrence of a series differs from cancelling the whole series; and how the model stays open to a new recurrence rule (say, 'first Monday monthly') without editing existing booking classes.
Requirements
This assessment is a Premium feature.
The statement above is free to read. The functional and non-functional requirements, and the graded canvas that scores your design against them, come with Premium.
Topics
- System Design LLD
- Oop Solid
- Patterns Strategy
- Statemachine
- Concurrency Locks