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
40 min · hard
hard

Design a Meeting Scheduler system that allows multiple users to book meetings in various rooms, manages attendee availability, detects scheduling conflicts, and supports recurring events with flexible recurrence rules.

Given Info
  • Rooms have fixed capacities and can be booked for meetings.
  • Attendees can have multiple meetings but cannot be double-booked at overlapping times.
  • Meetings can be one-time or recurring with daily, weekly, or monthly patterns.
  • The system must detect and prevent scheduling conflicts for rooms and attendees.
  • Concurrent booking requests can occur, requiring thread-safe operations.
📋
Guided Steps
1/5
Step 1
Define core domain entities and their relationships
Identify and design the main classes such as Room, Attendee, Meeting, and RecurrenceRule. Specify their relationships and ownership.
💡 Hint
Use composition for entities that cannot exist independently (e.g., Meeting owns RecurrenceRule). Use aggregation or association where appropriate. Use enums for fixed types like MeetingStatus.
Key Decision
abstract class Meeting with instance fields (startTime, endTime, attendees) - abstract because it holds shared state; interface cannot hold instance fields in Java
Interviewer Expectation
Mid: Defines classes and relationships with correct cardinality. Senior: Explains composition vs aggregation lifecycle ownership and why Meeting owns RecurrenceRule (composition).
⚠️Common Wrong Answer
Using interfaces for Meeting and RecurrenceRule leads to inability to hold shared instance state like startTime and recurrence pattern, causing scattered state management.
Step 2
Design conflict detection logic for rooms and attendees
Implement methods to check if a room or attendee is available for a given time slot, including recurring meetings.
💡 Hint
Use synchronized boolean isAvailable(TimeSlot slot) in Room and Attendee to atomically check availability. Use java.time classes for time representation.
Key Decision
synchronized boolean isAvailable(TimeSlot slot) in Room and Attendee - synchronized to prevent race conditions during concurrent availability checks and bookings
Interviewer Expectation
Mid: Implements conflict detection methods. Senior: Explains exact thread interleaving where two threads check availability simultaneously without synchronization causing double booking.
⚠️Common Wrong Answer
Not synchronizing availability checks allows two threads to read available status simultaneously, both proceed to book, causing double booking at runtime.
Step 3
Implement recurring event support with flexible recurrence rules
Design a RecurrenceRule class hierarchy to support daily, weekly, and monthly recurrences. Integrate with Meeting to generate occurrences.
💡 Hint
Use abstract class RecurrenceRule with concrete subclasses DailyRecurrenceRule, WeeklyRecurrenceRule, MonthlyRecurrenceRule holding recurrence state. Use enum for recurrence frequency.
Key Decision
abstract class RecurrenceRule with instance fields (frequency, interval) - abstract to hold shared recurrence state; interface cannot hold fields in Java
Interviewer Expectation
Mid: Defines recurrence subclasses and integrates with Meeting. Senior: Explains why abstract class is chosen over interface due to shared state and method implementations.
⚠️Common Wrong Answer
Using interface for RecurrenceRule forces all state to be external, scattering recurrence logic and increasing complexity.
Step 4
Ensure thread-safe booking and cancellation of meetings
Design methods to book and cancel meetings atomically, updating room and attendee schedules safely under concurrency.
💡 Hint
Use synchronized boolean bookMeeting(Meeting m) in Room and Attendee to atomically check availability and add meeting. Use volatile flags if needed to track booking status.
Key Decision
synchronized boolean bookMeeting(Meeting m) - atomic check-and-set to prevent race conditions; volatile not needed here as synchronization provides happens-before guarantees
Interviewer Expectation
Mid: Implements synchronized booking methods. Senior: Traces thread interleaving where lack of synchronization leads to inconsistent state and double booking.
⚠️Common Wrong Answer
Using volatile alone without synchronization leads to visibility but not atomicity, allowing race conditions during booking.
Step 5
Design attendee availability considering recurring meetings
Extend attendee availability checks to consider recurring meetings and exceptions (e.g., canceled occurrences).
💡 Hint
Store occurrences generated from RecurrenceRule in Meeting. Use synchronized methods to check attendee schedule including all occurrences.
Key Decision
synchronized boolean isAvailable(TimeSlot slot) in Attendee considers all Meeting occurrences - synchronization ensures consistent view of schedule under concurrency
Interviewer Expectation
Mid: Checks availability including recurring meetings. Senior: Explains how synchronization prevents stale reads of attendee schedule during concurrent updates.
⚠️Common Wrong Answer
Ignoring recurring occurrences in availability leads to scheduling conflicts; not synchronizing causes stale or inconsistent schedule views.
🔌
API Design Challenge
Design APIs that allow clients to create, update, and cancel meetings, query room and attendee availability, and handle recurring meeting exceptions efficiently.
Hints
  • Use RESTful endpoints with clear resource naming such as /meetings, /rooms, /attendees.
  • Support query parameters for filtering availability by time range and recurrence.
  • Design idempotent booking APIs to handle retries safely under concurrency.
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • abstract classes for entities with shared instance state (Meeting, RecurrenceRule)
  • enums for fixed types (MeetingStatus, RecurrenceFrequency)
  • synchronized methods for atomic availability checks and bookings
  • composition relationship for Meeting owns RecurrenceRule with lifecycle dependency
  • java.time API usage for time representation
Good to Have - 30%
  • thread-safe collections for managing Rooms and Attendees
  • detailed concurrency reasoning with thread interleaving examples
  • handling exceptions in recurring meetings (cancellations, reschedules)
  • efficient occurrence generation and caching for recurring meetings
  • fine-grained locking to reduce contention
Bonus - 10%
  • support for complex recurrence rules (e.g., nth weekday of month)
Anti-patterns to Avoid
✅
Model Answer
▼ Reveal

This design uses Java abstract classes Meeting and RecurrenceRule to encapsulate shared state and behavior, ensuring clean domain modeling. Synchronization on availability and booking methods prevents race conditions and double bookings under concurrency. RecurrenceRule subclasses support flexible recurrence patterns, and Meeting owns RecurrenceRule via composition to enforce lifecycle dependency. The system uses java.time API for immutable and precise time handling. Thread-safe collections like ConcurrentHashMap manage Rooms and Attendees concurrently. The design includes APIs for booking, cancellation, and querying availability, supporting recurring meetings and exceptions.

Key Decisions
  • Use abstract classes Meeting and RecurrenceRule to hold shared instance state and behavior because interfaces cannot hold fields in Java
  • Synchronize isAvailable(TimeSlot) and bookMeeting(Meeting) methods in Room and Attendee to ensure atomicity and prevent race conditions
  • Use composition for Meeting owning RecurrenceRule to enforce lifecycle dependency; RecurrenceRule cannot exist independently
  • Use java.time classes (LocalDateTime, Duration) for immutable and precise time representation
  • Design APIs to be idempotent and thread-safe, supporting recurring meetings and exceptions
  • Use thread-safe collections like ConcurrentHashMap for managing Rooms and Attendees concurrently
  • Use abstract classes (Meeting, RecurrenceRule) to hold shared instance state and behavior; interfaces cannot hold fields in Java.
  • Use enums for fixed types like MeetingStatus and RecurrenceFrequency to ensure compile-time safety and exhaustive switch statements.
  • Synchronize availability and booking methods (e.g., synchronized boolean isAvailable(TimeSlot), synchronized boolean bookMeeting(Meeting)) to prevent race conditions and double booking.
  • Use composition for Meeting owning RecurrenceRule to enforce lifecycle dependency; RecurrenceRule cannot exist without Meeting.
  • Use java.time classes (LocalDateTime, Duration) for precise and immutable time representation.
  • Trace exact thread interleavings causing conflicts: e.g., two threads reading availability simultaneously without synchronization leading to double booking.
  • Avoid volatile alone for atomic operations; synchronization provides atomicity and visibility guarantees together.
  • Store generated occurrences of recurring meetings to simplify conflict detection and availability checks.
  • Design MeetingScheduler as a coordinator class managing Rooms and Attendees with thread-safe collections (e.g., ConcurrentHashMap) for concurrent access.
  • Use synchronized blocks or methods rather than coarse-grained locking to minimize contention and improve scalability.

Practice

(1/5)
1. A class has a private constructor and a static synchronized getInstance() method that returns the single instance. Which design pattern is applied here and why is this the CORRECT use case?
easy
A. Singleton pattern, because it ensures only one instance exists and provides global access.
B. Factory Method pattern, because it controls object creation through a static method.
C. Builder pattern, because it constructs complex objects step-by-step.
D. Prototype pattern, because it clones existing instances to create new ones.

Solution

  1. Step 1: Identify the pattern from constructor and method signature

    The private constructor prevents external instantiation, and the static synchronized getInstance() method controls instance creation, which matches Singleton pattern characteristics.

  2. Step 2: Explain why Singleton fits this use case

    Singleton ensures a single instance with thread-safe access via synchronization, suitable for shared resources like configuration or logging.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Private constructor + synchronized static getInstance() -> Singleton pattern [check]
Hint: Private constructor + static synchronized getInstance() -> Singleton [check]
Common Mistakes:
2. In the Amazon Locker Service, if the assignLocker() method is not synchronized, which exact sequence of thread interleaving causes two packages to be assigned the same locker?
medium
A. Thread 1 assigns locker and updates status; Thread 2 waits until Thread 1 finishes, then assigns a different locker.
B. Thread 1 and Thread 2 both call assignLocker() simultaneously and both fail to find any available lockers.
C. Thread 1 checks locker availability -> true, context switch; Thread 2 checks availability -> true; both assign the same locker before status update.
D. Thread 1 releases a locker; Thread 2 immediately assigns it without checking availability.

Solution

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

    Without synchronization, Thread 1 reads locker as available, then context switches before marking it occupied.

  2. Step 2: Thread 2 also reads locker as available and proceeds to assign it, causing double-booking.

    Both threads assign the same locker before either updates the status.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Check-then-act gap -> double assignment [check]
Hint: Check availability -> context switch -> both assign same locker [check]
Common Mistakes:
3. The Elevator System currently calculates fees using a fixed rate. To add a WeekendFeeStrategy without modifying existing classes, which SOLID principle is being applied and what is the minimal required change?
medium
A. Single Responsibility Principle: modify ElevatorController to handle weekend fees directly.
B. Liskov Substitution Principle: replace FeeStrategy with WeekendFeeStrategy everywhere in the codebase.
C. Dependency Inversion Principle: inject WeekendFeeStrategy into Elevator class by modifying its constructor.
D. Open/Closed Principle: create a new WeekendFeeStrategy class implementing FeeStrategy interface; no changes to existing classes.

Solution

  1. Step 1: Identify SOLID principle

    Open/Closed Principle (OCP) states software entities should be open for extension but closed for modification.

  2. Step 2: Apply OCP via new strategy class

    Adding WeekendFeeStrategy as a new implementation of FeeStrategy extends behavior without modifying existing classes.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    New strategy class extends fees without changing existing code [check]
Hint: OCP: extend with new class, don't modify existing code [check]
Common Mistakes:
4. In the Facebook design, the FriendRequestManager class has a sendRequest() method that checks if a friend request exists before creating one. Without synchronization, which exact thread interleaving causes duplicate friend requests?
medium
A. Thread 1 sends request, Thread 2 waits until Thread 1 finishes, then sends request.
B. Thread 1 and Thread 2 both block on a lock, preventing duplicate requests.
C. Thread 1 creates request, Thread 2 reads request and cancels its own creation.
D. Thread 1 checks no request exists, context switch; Thread 2 checks no request exists, both create requests.

Solution

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

    Both threads check for existing request before creation; without synchronization, both see none.

  2. Step 2: Trace thread interleaving

    Thread 1 checks and pauses before creating; Thread 2 checks and proceeds; both create duplicate requests.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Unsynchronized check-then-act -> duplicate friend requests [check]
Hint: Check-then-act without lock -> race condition [check]
Common Mistakes:
5. To add a WeekendFeeStrategy for weekend parking fees without modifying existing classes, which SOLID principle is being applied and what is the minimum required change?
medium
A. Single Responsibility Principle: modify ParkingLot to handle weekend fees directly.
B. Dependency Inversion Principle: hardcode weekend fee logic inside ParkingLot's fee calculation.
C. Open/Closed Principle: create a new WeekendFeeStrategy class implementing FeeStrategy; inject it without changing ParkingLot.
D. Liskov Substitution Principle: subclass ParkingLot to override fee calculation for weekends.

Solution

  1. Step 1: Identify SOLID principle for extensibility

    Open/Closed Principle states software entities should be open for extension but closed for modification.

  2. Step 2: Apply OCP by adding new WeekendFeeStrategy implementing FeeStrategy interface without modifying ParkingLot.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    New strategy class added, existing classes unchanged -> OCP respected [check]
Hint: OCP: extend with new class, don't modify existing ones [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