Bird
Raised Fist0

Design a Meeting Scheduler - Rooms, Attendees, Conflicts, Recurring Events

LLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Design a Meeting Scheduler - Rooms, Attendees, Conflicts, Recurring Events
Design a robust meeting scheduler handling rooms, attendees, conflicts, and recurring events with concurrency control.
mediumBooking and Reservation SystemsFreq: high
Prerequisites:OOP FundamentalsJava Concurrency BasicsDesign Patterns (Factory, Observer, Strategy)Collections Framework
⚙️
Functional Requirements
  • System must allow booking of rooms for meetings with multiple attendees
  • Prevent double-booking of rooms and attendees at overlapping times
  • Support recurring meetings with daily, weekly, monthly patterns
  • Allow querying of meetings by room, attendee, or time range
  • Provide conflict detection and resolution mechanisms
  • Allow cancellation and rescheduling of meetings
  • Notify attendees asynchronously on meeting updates
👤
Use Cases
  • Create a meeting with specified attendees and room
  • Check room availability for a given time slot
  • Detect and resolve scheduling conflicts for attendees and rooms
  • Support recurring meetings with customizable recurrence rules
  • Cancel or reschedule meetings
  • Notify attendees of meeting changes
🧑‍💻
Actors
  • Organizer
  • Attendee
  • System Scheduler
  • Room Manager
❓
Clarifying Questions to Ask
  • How many concurrent threads/gates will access the scheduler? (Expected concurrency level)
  • Is there a pricing or cost model for room bookings? (Currently no pricing)
  • How should conflicts be resolved? Automatically or via user intervention?
  • Are recurring events allowed to have exceptions (e.g., skip a date)?
  • What is the expected maximum number of attendees per meeting?
  • Should notifications be synchronous or asynchronous?
  • Are rooms shared resources or dedicated per department?
Out of Scope
✗ Integration with external calendar systems (e.g., Google Calendar)
✗ Pricing or payment for room bookings
✗ Physical access control to rooms
✗ Detailed UI/UX design
⚡
QPS Calculation
read qps500
write qps100
🖥️
Server Estimate
3
Estimate based on expected medium concurrency and data volume for a mid-sized org.
🔢
Enumerations
enum MeetingStatus
SCHEDULED | CANCELLED | COMPLETED
Defines lifecycle states of a meeting to prevent invalid operations and enable state-based logic.
enum RecurrenceFrequency
DAILY | WEEKLY | MONTHLY | YEARLY | NONE
Encapsulates recurrence patterns for meetings, enabling extensible and type-safe recurrence handling.
enum RoomType
CONFERENCE | HALL | CABIN | AUDITORIUM
Classifies rooms by type to support filtering and capacity planning.
enum NotificationType
EMAIL | SMS | PUSH
Defines notification channels for attendee alerts, enabling extensible notification strategies.
📦
Meeting
8 fields
private final String meetingIdprivate String titleprivate volatile MeetingStatus statusprivate final Room roomprivate final List<Attendee> attendeesprivate final LocalDateTime startTimeprivate final LocalDateTime endTimeprivate final RecurrenceRule recurrenceRule
Represents a scheduled meeting with attendees, room, timing, and recurrence. Manages state transitions and conflict checks.
Key Methods
public synchronized boolean schedule()Atomically schedules the meeting if no conflicts exist; returns true if successful.
public synchronized void cancel()Cancels the meeting and updates status atomically.
public boolean conflictsWith(Meeting other)Checks if this meeting conflicts in time and room or attendees with another meeting.
public List<MeetingOccurrence> getOccurrences(LocalDateTime from, LocalDateTime to)Returns all occurrences of this meeting within the specified date range considering recurrence.
📦
Room
4 fields
private final String roomIdprivate final RoomType typeprivate final int capacityprivate volatile boolean isAvailable
Represents a physical room with capacity and type. Tracks availability for scheduling.
Key Methods
public synchronized boolean isAvailable(LocalDateTime start, LocalDateTime end)Checks if the room is free for the given time slot.
public synchronized boolean reserve(LocalDateTime start, LocalDateTime end)Atomically reserves the room for the given time slot if available.
public synchronized void release(LocalDateTime start, LocalDateTime end)Releases the room reservation for the given time slot.
📦
Attendee
3 fields
private final String attendeeIdprivate final String nameprivate final String email
Represents a meeting participant with contact details.
Key Methods
public void notify(Notification notification)Sends a notification to the attendee asynchronously.
📦
RecurrenceRule
4 fields
private final RecurrenceFrequency frequencyprivate final int intervalprivate final LocalDateTime untilprivate final List<LocalDateTime> exceptions
Defines recurrence pattern and exceptions for recurring meetings.
Key Methods
public LocalDateTime getNextOccurrence(LocalDateTime after)Calculates the next occurrence after the given date considering exceptions.
public boolean isRecurring()Returns true if frequency is not NONE.
📦
MeetingOccurrence
3 fields
private final Meeting meetingprivate final LocalDateTime occurrenceStartprivate final LocalDateTime occurrenceEnd
Represents a single occurrence of a recurring meeting.
Key Methods
public Duration getDuration()Returns the duration of this occurrence.
📦
Notification
3 fields
private final NotificationType typeprivate final String messageprivate final LocalDateTime timestamp
Encapsulates notification details sent to attendees.
Key Methods
public void send(Attendee attendee)Sends the notification to the specified attendee.
📦
Scheduler
3 fields
private final Map<String, Meeting> meetingsprivate final Map<String, Room> roomsprivate final Map<String, Attendee> attendees
Central coordinator for scheduling meetings, managing rooms and attendees, and conflict detection.
Key Methods
public synchronized Meeting createMeeting(String title, Room room, List<Attendee> attendees, LocalDateTime start, LocalDateTime end, RecurrenceRule recurrenceRule)Creates and schedules a new meeting if no conflicts exist.
public synchronized void cancelMeeting(String meetingId)Cancels the meeting by ID and notifies attendees.
public synchronized boolean rescheduleMeeting(String meetingId, LocalDateTime newStart, LocalDateTime newEnd)Reschedules an existing meeting if no conflicts exist.
public List<Meeting> getMeetingsByRoom(String roomId, LocalDateTime from, LocalDateTime to)Returns meetings scheduled in a room within a time range.
public List<Meeting> getMeetingsByAttendee(String attendeeId, LocalDateTime from, LocalDateTime to)Returns meetings for an attendee within a time range.
🗄️
Meetings
PK: meetingId
meetingId STRINGtitle STRINGstatus STRINGroomId STRINGstartTime TIMESTAMPendTime TIMESTAMPrecurrenceRule STRING
🗄️
RoomReservations
PK: roomId
roomId STRINGmeetingId STRINGstartTime TIMESTAMPendTime TIMESTAMP
🔌
POST /meetings
Request
{
  "title": "string",
  "roomId": "string",
  "attendeeIds": [
    "string"
  ],
  "startTime": "ISO8601 datetime",
  "endTime": "ISO8601 datetime",
  "recurrenceRule": "optional recurrence pattern"
}
Response
{
  "meetingId": "string",
  "status": "string"
}
Creates and schedules a new meeting if no conflicts.
🔌
POST /meetings/{meetingId}/cancel
Request
{}
Response
{
  "success": "boolean"
}
Cancels a meeting and notifies attendees.
🔌
GET /rooms/{roomId}/availability
Request
{
  "startTime": "ISO8601 datetime",
  "endTime": "ISO8601 datetime"
}
Response
{
  "available": "boolean"
}
Checks if a room is available for the given time slot.

Practice

(1/5)
1. To add a WeekendFeeStrategy for weekend pricing in the current booking system design, which minimal change respects the Open-Closed Principle (OCP)?
medium
A. Modify the existing FeeCalculator class to add weekend logic with if-else conditions.
B. Create a new class implementing FeeStrategy interface for weekend fees and inject it without changing existing classes.
C. Add a boolean flag isWeekend in Booking and handle fees there.
D. Extend FeeCalculator with a subclass that overrides fee calculation for weekends.

Solution

  1. Step 1: Identify OCP requirement

    OCP requires adding new functionality without modifying existing tested code.

  2. Step 2: Evaluate options

    Add a boolean flag isWeekend in Booking and handle fees there. adds weekend flag in Booking, which violates OCP by modifying Booking class. Create a new class implementing FeeStrategy interface for weekend fees and inject it without changing existing classes. creates a new FeeStrategy class, respecting OCP by extension. Modify the existing FeeCalculator class to add weekend logic with if-else conditions. and D modify existing classes, violating OCP.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    New FeeStrategy class -> extend without modifying existing code [check]
Hint: New strategy class -> extend, don't modify [check]
Common Mistakes:
2. In the Airline Reservation System, if the reserveSeat() method is not synchronized, which exact sequence of thread interleaving causes double-booking of the same seat?
medium
A. Thread 1 and Thread 2 both fail to read seat status due to visibility issues, causing booking failure.
B. Thread 1 reads seat as available, Thread 2 reads seat as unavailable, both proceed to book.
C. Thread 1 locks seat, Thread 2 waits; Thread 1 releases lock after booking.
D. Thread 1 checks seat availability -> true, context switch before booking; Thread 2 checks availability -> true, both book seat.

Solution

  1. Step 1: Identify the check-then-act race condition

    Without synchronization, Thread 1 reads seat as available but is preempted before booking; Thread 2 also reads available and proceeds.

  2. Step 2: Both threads book the same seat concurrently

    Because no lock or atomic operation protects the check-and-book sequence, double-booking occurs.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Check-then-act gap without synchronization -> double-booking [check]
Hint: Check seat available -> context switch -> both book [check]
Common Mistakes:
3. The Blackjack game needs to support ElectricCar players who require ChargingSpot betting spots. What is the minimum design change to support this without modifying existing classes?
hard
A. Add ELECTRIC_CAR to VehicleType, CHARGING to SpotType, create ElectricCar extending Vehicle, and update compatibility map externally
B. Modify Vehicle and Spot classes to include electric-specific logic and fields
C. Create a new ElectricCarVehicle and ChargingSpot classes inheriting from existing ones and modify base classes to support them
D. Add electric-specific flags and logic inside existing Vehicle and Spot classes

Solution

  1. Step 1: Identify extensibility without modifying existing classes

    Adding new enum values and subclasses externally allows extension without changing existing code, respecting OCP.

  2. Step 2: Why other options violate OCP or cause class explosion

    Options B and D modify existing classes, violating OCP; Create a new ElectricCarVehicle and ChargingSpot classes inheriting from existing ones and modify base classes to support them creates new classes but requires base class changes.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Extend enums + subclass + external compatibility map -> minimal change [check]
Hint: Extend enums + subclass + external map -> no existing class change [check]
Common Mistakes:
4. The system needs to support ElectricCar and ChargingSpot without modifying existing classes. What is the minimum change to the current design to support this?
hard
A. Create a new ElectricCar class and ChargingSpot class, then modify Cart and Order to handle them explicitly.
B. Modify Vehicle class to add isElectric flag and add logic for charging spots inside existing methods.
C. Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar subclass, update SpotCompatibility map; no existing class changes.
D. Add a new interface Chargeable and implement it in ElectricCar and ChargingSpot, modifying existing classes to check for it.

Solution

  1. Step 1: Identify extensibility without modifying existing classes

    Adding new enum values and new subclasses allows extension without changing existing class code.

  2. Step 2: Update SpotCompatibility map to include new types

    Updating compatibility map is a configuration change, not a class modification, preserving OCP.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Enum extension + new subclasses + compatibility map update -> no existing class change [check]
Hint: Extend enums + subclasses + config map -> no class edits [check]
Common Mistakes:
5. ElectricCar requires ChargingSpots in the parking system. What is the minimum change to support this without modifying existing classes, ensuring extensibility and avoiding class explosion?
hard
A. Modify Vehicle class to include a boolean isElectric field and add charging logic inside existing methods.
B. Add charging spot logic inside ParkingLot class and modify parkVehicle() to check for electric cars.
C. Create a new ElectricCarChargingFacade class that extends ParkingLot and handles charging spots separately.
D. Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar subclass, and update SpotCompatibility.COMPATIBILITY_MAP accordingly.

Solution

  1. Step 1: Identify extensibility without modifying existing classes

    Adding new enum values and subclass ElectricCar extends Vehicle allows new types without changing existing code.

  2. Step 2: Update SpotCompatibility.COMPATIBILITY_MAP to include new compatibility rules for charging spots.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    New enums and subclass added, existing classes unchanged -> extensible design [check]
Hint: Add enums and subclass; update compatibility map, no existing class changes [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard