Getting Ready: Meeting Scheduler

Every organization — from a 5-person startup to a 200,000-employee enterprise — relies on a Meeting Scheduler. Products like Google Calendar, Microsoft Outlook, Calendly, and Zoom Scheduler collectively coordinate billions of meetings per year. Google Calendar alone serves over 500 million users, and Microsoft Outlook manages calendars for more than 400 million commercial accounts.

What makes the Meeting Scheduler an excellent medium-difficulty LLD problem is the intersection of several design challenges in one compact system:

• Interval scheduling and conflict detection — When a user tries to book a meeting from 2:00 PM to 3:00 PM, the system must efficiently check whether any existing meeting overlaps with that time window. This requires a well-designed calendar data structure and an O(n) or O(log n) conflict-detection algorithm — not a naive nested loop.
• Multi-participant coordination — A meeting involves an organizer and one or more invitees. Each invitee has their own calendar. Scheduling a meeting requires checking availability across ALL participants, not just the organizer. This introduces the complexity of cross-calendar queries.
• Recurring meetings — Real schedulers support daily, weekly, and monthly recurrence patterns ("Every Monday at 10 AM for 12 weeks"). This means a single meeting definition can generate dozens of concrete time slots — each of which must pass conflict checks. Modeling recurrence cleanly without duplicating logic is a genuine design challenge.
• Invitation lifecycle — Invitees can accept, decline, or tentatively accept a meeting invitation. The organizer needs to be notified when responses arrive. This is a textbook application of the Observer Pattern.

This problem appears frequently in LLD interviews at companies like Google, Microsoft, Amazon, and Salesforce because it tests whether candidates can model a system with overlapping time intervals, multi-entity coordination, and event-driven notifications — challenges that mirror real calendar infrastructure.

By the end of this design problem, you will be able to:

• Design an interval-based conflict detection system — model calendar time slots and efficiently detect overlapping meetings using sorted intervals
• Coordinate multi-participant scheduling — build a system where meetings reference multiple user calendars and validate availability across all participants
• Model recurring meetings — implement recurrence patterns (daily, weekly, monthly) that expand into individual occurrences, each independently conflict-checked
• Apply the Builder Pattern — construct complex Meeting objects with many optional fields (recurrence, room, reminder) without telescoping constructors
• Apply the Observer Pattern — notify participants of invitation changes, meeting updates, and cancellations through a decoupled notification mechanism
• Create three UML diagrams — Use Case Diagram (actor interactions), Class Diagram (structural blueprint), and Sequence Diagram (meeting scheduling flow)
• Write complete implementations in Python and Java that match the UML design exactly

Before starting this problem, make sure you're comfortable with:

• OOP Relationships — especially Composition (Calendar owns Meetings) and Association (Meeting references Users) — Fundamentals S4
• Inheritance & Polymorphism — for recurrence pattern hierarchy and notification channels — Fundamentals S3
• Builder Pattern — how to construct complex objects step by step without a massive constructor — Fundamentals S10
• Observer Pattern — how subjects notify observers of state changes (used for invitation responses and meeting updates) — Fundamentals S12
• UML Class Diagrams — reading class boxes, relationship arrows, and multiplicities — Fundamentals S5
• UML Sequence Diagrams — reading lifelines, messages, and activation bars — Fundamentals S5

If you've completed the easy design problems (DP1-DP7), you already have hands-on experience with these concepts. This problem combines them with the added complexity of time-based interval logic.

We will design: The core domain logic of a Meeting Scheduler — user and calendar management, meeting creation with single and recurring patterns, calendar conflict detection, room booking, invitation lifecycle (send/accept/decline), and notification triggers. All modeled as an object-oriented system with clear class hierarchies and design patterns.

We will NOT design: Database schemas, REST API endpoints, distributed calendar sync protocols (CalDAV/iCal), timezone conversion logic, UI rendering, or video conferencing integration. This is a Low Level Design (object-oriented) exercise, not a System Design (infrastructure) problem.

Key distinction from similar problems:

• Unlike the Hotel Management System (DP14), which manages room state transitions (Available → Reserved → Occupied → Maintenance), the Meeting Scheduler manages time-interval conflicts across multiple participant calendars
• Unlike the Movie Ticket Booking System (DP19), which focuses on concurrent seat locking within a single showtime, the Meeting Scheduler focuses on cross-calendar availability queries and recurring event expansion
• Unlike the Task Management System (DP7), which tracks task status and assignment, the Meeting Scheduler deals with temporal constraints — meetings have start times, end times, and must not overlap