Design a Meeting Scheduler (Low-Level Design)

🟠 Low-Level Design · Case Study · Senior

"Design a meeting scheduler" (think the Google Calendar / Outlook booking flow) is a favourite because underneath the simple product sits a classic algorithmic core: interval overlap. The design is mostly about modelling calendars and rooms cleanly, then answering "is this slot free?" and "when are we all free?" efficiently. Let's build it.

Step 1 — Requirements

• Functional: book a meeting for a time range with a set of attendees and a room; reject if any attendee or the room is double-booked; find the earliest common free slot; send invites; support cancel.
• Non-functional: correct overlap detection, fast availability queries, extensible to recurring meetings and time zones.

Step 2 — The classes

• Interval — start & end time; knows how to test overlaps(other).
• Meeting — an Interval + organizer + attendees + room + title.
• Calendar — a sorted collection of a user's/room's booked Intervals; core ops: isFree(interval), book, cancel.
• User, MeetingRoom — each has a Calendar.
• SchedulerService — orchestrates booking + finding free slots + notifications.

Step 3 — The core: interval overlap

🟠 Everything hinges on one tiny, exact rule. Two intervals overlap iff a.start < b.end && b.start < a.end (using strict < so back-to-back meetings — one ends exactly when the next starts — are not a conflict). A slot is free for a calendar if it overlaps none of its booked intervals.

boolean overlaps(Interval a, Interval b) {
    return a.start < b.end && b.start < a.end;    // strict: touching endpoints don't clash
}
boolean isFree(Calendar cal, Interval slot) {
    for (Interval booked : cal.intervals)          // sorted; can binary-search / early-exit
        if (overlaps(booked, slot)) return false;
    return true;
}
boolean book(Meeting m) {
    boolean allFree = m.attendees.stream().allMatch(u -> u.calendar.isFree(m.interval))
                      && m.room.calendar.isFree(m.interval);
    if (!allFree) return false;                    // someone/room busy → reject
    // commit to every calendar atomically, then notify
}

Step 4 — Finding a common free slot

🔴 The senior follow-up: "find the earliest 30-min window everyone can make." Approach: take each attendee's busy intervals, merge them into one combined busy timeline (the classic merge-intervals problem), then the gaps between busy blocks are the common free windows — pick the first gap ≥ the requested duration. Keeping each calendar's intervals sorted makes the merge an O(n log n) sweep. Mentioning "merge everyone's busy intervals, then scan the gaps" is the standout answer.

Step 5 — The senior nuances

🔴 Where to earn extra marks:

• Atomic booking & concurrency: two organizers grabbing the last room slot simultaneously — you need a lock or optimistic check so only one wins (the same double-booking concern as seat reservation).
• Recurring meetings: store a rule (RRULE) rather than expanding thousands of instances.
• Time zones: store everything in UTC, render per user.
• Notifications = Observer: on book/cancel, notify attendees (reuse a notification service).

The interview-ready walkthrough

"Each User and Room has a Calendar of sorted Intervals. Booking a Meeting checks every attendee and the room is free via strict interval-overlap (a.start < b.end && b.start < a.end, so back-to-back is fine), then commits atomically and notifies. To find a common slot I merge everyone's busy intervals and scan the gaps for the first opening of the needed duration. I'd guard concurrent bookings with a lock, store recurring meetings as a rule, and keep times in UTC." Clean model plus the merge-intervals insight — that's the answer."

What to read next

• Design Ticketmaster — the same double-booking problem at scale
• Design a Notification Service — sends the invites
• Design a Food Delivery App — next up, the final case study
• ← The complete System Design guide (hub)

← Design Snake & Ladder · Design a food delivery app →