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.
• High availability for browsing and searching.

Non-Functional Requirements:

• List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...
• Horizontal Scalability
• Low latency
• High Availability for browsing and searching by having 99.99% uptime by having monitoring systems in place to check for metrics and based on the metrics scaling the infra. We can also have redundancy so that availability is high
• Strong Consistency by using transactions.

API Design

GET /api/v1/ListRooms?capacity=100×lot=9:00&location=vij&equipment=projector

POST /api/v1/CreateBooking?room=1&time=9:00

PUT /api/v1/admin/UpdateBooking when this api is hit sendNotification endpoint is used to send the notification to the respective organizers and participants

DELETE /api/v1/admin/cancelBooking when this api is hit sendNotification endpoint is used to send the notification to the respective organizers and participants

POST /api/v1/SendNotification

POST /api/v1/authenticate

GET /api/v1/admin/Inventory

POST /api/v1/admin/ManageInventory

GET /api/v1/admin/Rooms

POST /api/v1/admin/AddRoom

DELETE /api/v1/admin/RemoveRoom

High-Level Design

Read Path: client -> cdn -> API Gateway -> Load Balancer -> Booking Service -> Kafka Queue -> Redis -> Mongo DB

Write Path: client -> CDN -> API Gateway -> Load Balancer -> Booking Service -> Kafka Queue -> Mongo DB -> Redis

Admin Path: Admin -> CDN -> API Gateway -> Load Balancer -> Admin Service -> Kafka Queue -> Redis -> Mongo DB

Notification service is used to send notification to the user of the status of their booking based on pub sub method.

We can have CDN and redis for caching and most of the reads will be taken care off by CDN if there is a miss it will come to redis and it misses there then only we will read from Mongo.

We will have a separate cleanup service to keep the redis and cdn from going stale.

Detailed Component Design

API Gateway routes the traffic based on the endpoint that is hit. This can also be used to ratelimit the requests to prevent DDoS and Brute force attacks. It can also be used for authentication.

Admin Service will handle all the admin related apis. This is only visible to the admins.

Booking service is where the bookings are done and is handled. It will help in booking and canceling the bookings.

Notification Service is used to send the status of the bookings and other related statuses to the respective user based on the PUB-SUB method. We can have a DLQ to check the reason for failure and have retry mechanism on failure.

Cleanup Service is used to clean the cache of stale data and invalidate the cache. Keeping the cache up to date.

We will be using the LRU eviction method in Redis to remove the entries in the cache. whenever a bookings change we will evict the entry from the cache related to that booking and push a new entry. when a cache miss happens the read happens on DB right after which that entry is made into the cache to avoid any more DB reads of the same entry.

We will be using Kafka Queue to write the data to redis and the db. Using this queue we can have cascading degradation meaning that even if some service goes down it can pick up where it left because the data is in the queue.

For concurrent bookings we can use database lock or transaction lock to prevent double bookings and such keeping the bookings clean.

We can have separate endpoint to collect and display the statistics of the room usage in admin service. It can be done using the usage, rating and other related metrics.