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:

• The room booking operations should be able to scale based on the traffic load. It must have availability of 99.999%.
• Room search and loop up operations cannot have latency larger than 50ms with availability of 99.99%.
• Room booking operation cannot have latency larger than 100 ms.
• Room confirmation message must be sent within 30 sec after the booking request is sent.
• Meeting reminder notification must be sent before 30 min prior to the meeting.

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...

Room's data structure

• roomId (GUID)
• displayName (string)
• capacity (short)
• building (string enum)
• floor (short)
• equipments (multi flags. e.g., Projector | Video)

Meeting data structure

• meetingId (GUID)
• owner (GUID)
• participants (list[GUID])
• startDateTime
• endDateTime
• status: (enum: Active, Cancel)
• roomId (GUID)
• roomConfirmationStatus (enum: NA (default), Confirmed, Rejected)
• lastUpdatedTime
• createdTime

API root: api/v1/

This API will have GraphQL supportsfor better query experience. Authentication is enabled by integrating with external identity provider.

Room availability

• AuthZ: default
• GET rooms/availability/filters=startdatetime, enddatetime, building, floor, capacity, equipments

Create meeting

• AuthZ: default
• POST meetings/

Room management

• AuthZ: Admin
• GET rooms/{roomId}
• POST rooms/{roomId}
• PATCH rooms/{roomId}
• DELETE rooms/{roomId}

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.

• The client requests will go to DNS for routing to the nearest datacenter per geo.
• Then the request will go through a load balancer to distribute the load across API gateway instances of the region.
• API gateway will talk to external identity provider for authN based on the request and required roles for the given operation. API gateway will also handle rate limit with token bucket and refill token rate to handler burst traffic. Then API gateway will route the business operation to related service pools.
• For room searching request, it will go to room searching microservice. Since we want the room information to be real-time accurate, it will query directly against the database with given filters.
• For room booking request, meeting microservice will put a meeting creation message into the message queue. Then the handler which listen to meeting creation event will write a meeting object into the database. The meeting object written event will put another message back to the message queue. Then room booking service will reserve the room async. Once a room is assigned or rejected, meeting notification service will listen to the event then send notification to the request owner based on booking success or failure.
• For meeting notification, there is a scheduler to periodically scan active meetings that will happen within the next 1 hour. Then put notification message into message queue to allow meeting notification service to pick up.
• The meeting notification service leverage external notification system (e.g. communication app, emails) for message delivery.
• As to room managing service, it will directly update room information in database. Potentially invalid any not processed messages in the queue that is related to the updated room based on policy (e.g. if a room is offline for maintaince, the related messages will be processed as rejected.

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.

To apply domain driven design, the room booking service manage "meeting aggregates" (data structured is mentioned in API design). the domain microservices with handlers design allow it to scale based on traffic. meeting operation will be put onto message queue so it can be managed across microservice instances. When a meeting handler is processing a room booking request. It will first create the meeting object in the database. Once the meeting object is created, the database (as an event source) will emit meeting created event back to the queue. Then room booking service will reserve the room async then trigger the required notification downstream.

For database writing strategy, writer will gain an aggregate's latest version when write a new record. If the version on an operation isn't the latest one, the operation will fail and we expect the caller to retry again.

Separating meeting creation from room booking as async operations will allow better system throughput.