Requirements

Functional Requirements:

• Allow users to browse and search available conference rooms by time slot, capacity, location (building/floor), and equipment (projector, video).
• Enable users to create, update, and cancel room bookings, including room, time, organizer, and optionally participants.
• Prevent double-booking of rooms by ensuring that concurrent booking attempts are serialized.
• Send users email or push notifications when a booking is confirmed, updated, or cancelled, and send reminder notifications before the meeting starts.
• Support user authentication and authorization with role-based access controls: regular users can book rooms, admins can manage room inventory and settings.

Non-Functional Requirements:

• Supports 10M-100M users
• 10K-100K QPS
• Assumptions:
  • Non global initially
  • Strong Consistency is very important for booking
    • No double bookings
  • Eventual consistency is find for search but search must be highly available
  • 1 write to 100 read ratio
  • Static webpage

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design

(RESTful APIs)

SearchAvailableRooms (time-slot, capacity, location, equipment)

POST

URL: rooms/search

RequestBody:

{

required timeslot

optional capacity

optional location

optional equipment

}

ResponseBody:

{

roomList

}

ManageBooking(create, update, cancel)

POST rooms//book

RequestBody:

{

users

timeslot

}

Status: 200 / 409 for conflict

ResponseBody: booking object

ManageRoom() <- admin only

POST

URL: rooms

RequestBody:

{

required roomId

required capacity

required location

required equipment

}

ResponseBody: room object

Status: 200

PUT/PATCH

URL: rooms

...

High-Level Design

Broken into micro services behind a Gateway (but could be modules in monolith).

Different APIs for

• Room management (admin only)
• Booking management (users / admin)
• Room search (users / admin)
• User auth (internally used by gateway for user auth)

Scheduling does not have an API it's an asynchronous triggered internal service.

RoomSearch has an asynchronous search index populated as it will be the hottest path of the system. It takes events from RoomDB and updates its search index.

Database Design

UserDB / RoomDB / UserAuth / BookingDB

• Not inherently relational
• Could be NoSQL DDB like storage
• Transaction behavior preferred
• Could have optimistic locking strategy or transactional writes and strongly consistent reads

RoomSearchIndex:

• Proper search database
• Async events from RoomDB and BookingDB are processed and applied
• Event ordering is crucial. Can have "skinny events" with call back for lates data
• OpenSearch

All DBs can be shared by organization.

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

(Omitted from HLD) Gateway can defer to LB before micro services. Allowing each stateless micro service to scale up horizontally.

Scheduling can receive async booking events via pub/sub mechanism. At which point it will store the schedule with time and place in its DB. It can either use an external scheduling service, or do its own scheduling logic with daily Cron invocations and scheduledAt db events. Scheduling service can read UserDB for contact information and also store its own user contact preferences.

BookingsDB will enforce transactional behavior.