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:

• Room search needs to be highly available (99%999) with low latency (<10ms)
• Room search is the hot path comparing to room booking. Its traffic must scale based on load.
• Room booking operation needs to be consistent (cannot have two meetings booked the same room. and once the room is booked for the meeting, it stays as booked)
• Meeting notification must be delivered within 1 min after the booking has updates (create, update, delete)

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

Data structure

Room

• roomId (unique key)
• building (partition key)
• floor
• capacity
• equipments

Meeting

• meetingId (unique key)
• owner
• participants
• startDateTime
• endDateTime
• roomId (partition key)

Search index

• Room: building, floor, capacity, equipments
• Meeting: startDateTime, endDateTime, roomId

API

API root: api/{version}

Search room

• AuthZ: regular user
• GET rooms/search?filter=...

Manage room

• AuthZ: admin
• POST rooms/ -> create room
• PATCH rooms/{roomId} -> update room
• DELETE rooms/{roomId} -> delete room

Book meetings

• AuthZ: regular user
• POST meetings/ -> create meeting

Manage meeting

• AuthZ: meeting owner
• PATCH meetings/{meetingId} -> update meeting
• DELETE meetings/{meetingId} -> delete/cancel meeting

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

• DNS: Route request to the nearest datacenter per geo
• Load balancer: Distributed traffic among API gateway instances of the region.
• API gateway: API version, rate limit, AuthN, route request to service. AuthN is connected to external identity provider
• Room search microservice: Find available room based on the meeting request.
• Meeting microservice: Create a meeting with a room. Also responsible for update/cancel (delete) a meeting.
• Room mgr microservice: create/update/delete meeting room.
• Search index: optimize room search speed. search index is described in API design.
• Document DB should be enough. Don't need to use relational database.
• Database read replica: handle read operations (e.g. search room)
• Database primary: handle write operations (e.g., book meeting, update meeting, update room, ... etc)
• Message queue: queue notification requests as an async operations
• Notification microservice: process message queue to send different notification by calling external notification provider (e.g., email, communication app)

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.

Room search microservice:

• Room and meeting are indexed for search (e.g., room location, meeting start and end time).
• Search index can be refreshed by scheduler.
• Search index is created from read replica of the database.
• When finding an available room, the service will query search index to find existing meetings for the given start and endtime. So the room of these meetings cannot be select. By querying the total rooms and minus the occupied rooms, the remaining rooms are available to book.

Meeting microservice:

• It handles meeting lifecycle: create, update, delete.
• Only meeting owner can update/delete his/her meetings.
• It writes directly to primary database which is reserved for write operation.
• For concurrent writes, it uses meeting room+starttime+endtime lock. Only the caller who acquires the lock can write to DB on the given room and time slot. The later caller operation will fail due to the meeting for the room of a given slot has been occupied.
• Once a meeting is booked. it will raise an event to message queue for async notifications (email to participants)

Room mgr service:

• It handles room inventory and settings.
• Only admin can perform the operation.
• Once a meeting room is offline, it will invalid related meetings for the room within a given time slots and raise events to message queue for notification.

High availability

• Read is the hot path of the system. By enabling search index and separate read and write operations against different DB, we ensure the read/search operations has high throughput.
• When peak traffic happened, it will first be gated by API gateway with token bucket mechanism - end users will be throttle based on IPs.
• Besides, meeting is partition by roomId. Room is partition by location. it can make query faster.