System requirements

Functional:

1. consider each meeting room as a person and have a calendar assigned to each room
2. Employees can see the list of available meeting rooms within an organization
3. Look at the calendar of each meeting room
4. The calendar displays booked and available slots
5. Employees can book one or more meeting rooms if slot is free
6. Employees can cancel the booked slot, if cancelled make the slot available to others

Non-Functional:

1. Strong consistency is the key thing because, if two persons try to book the same room at the same time, it is not allowed.
2. Availability - System should have high availability
3. scalable to accommodate more employees and more rooms. But still guess the numbers won't be that huge.
4. Usability - User friendly UI

Capacity estimation

No. of employees = 100K

No of rooms = 100

consider, 10K employees try to book a room on a single day

Max request per day = 10000 * 100 = 1M

Request Per Second = 10

Storage capacity = employee info * meeting room info = 100 bytes

100 *100 = 10000 bytes = 10KB per day

Per month = 300 KB

API design

GET /show_all_rooms

• return all the meeting room names with capacity

GET /rooms/available

• return the list of available rooms, can be all, filter like date, by slot

GET /room/{:id}

• return details about the particular meeting room, like room name, room_id, room capacity, floor detail, block detail, available facilities:{}, whole weekly calendar for that room

/POST /room/book/{:id}

• i/p - room_id, user_id, date, start_time, end_time
• status - success or failure, if success return booking_id

/DELETE /room/cancel/{:booking_id}

• i/p - booking_id
• status - success or failure

Database design

1. rooms_db

• room_id:int(PK)
• room_name:string
• block_id:int
• floor_id:int
• capacity:json
• facilities_available:json
• calender_id:int

1. calendar

• calender_id:int (PK)
• room_id:int (FK)
• booking_id:int (FK)

1. bookings

• booking_id:int(PK)
• user_id:int(FK)
• room_id:int(FK)
• date:string
• start_time:string
• end_time:string
• peope_count:JSON

High-level design

Core entities:

1. Room Service
2. Calendar Service
3. Booking Service
4. Notification Service

Room service:

This service has access to rooms_db from which it can serve list of rooms in the organization, with various filters like rooms in a block, a floor, particular date, particular time period or even based on availability

Calendar Service:

This service is the one responsible to display the calendar in UI with information like booked slot, available slot. UI display it in a weekly, monthly or day view, based on user preference

Booking service:

Handles events like booking a room if already not booked, canceling a room by booking_id. Interacts with bookings_db to fetch the information & update the same.

Notification Service:

Incase of events like booking success or cancellation of booking, sends notification to the user.

Note:

1. We need to design a system that supports - exactly once strategy, that is - booking should happen at least & almost once.This can be achieved using retry and idempotency
2. These services run as multiple instances, ensuring reliability and availability
3. Caching frequently accessed data in cache, helps us achieve low latency.

Request flows

1. user: send request to view calendar of a meeting room
2. Room Service: receive request, talk to calendar & booking service and return the info
3. User: initiate a book room request
4. Room Service: receive the request and validate the req with booking service and process the req accordingly
5. User: initiate cancel request
6. Room Service: receive the request and validate the req with booking service and process the req accordingly

Detailed component design

Room Service:

Handles are the incoming request like view room details, booking and cancel request.

The details about the most frequently used rooms cached in Redis and served.

Static room details can be cached in redis

Trade offs/Tech choices

Tech Choices:

1. We take advantage of microservice architecture and split the functionality to different microservices.
2. The communication Protocol is HTTPS, since everything is a client initiated request.
3. Choice of Database would be SQL DB, as we need to serve consistency.
4. Reads > writes, hence can have single leader, multi follower for reads, by distributing the load.

Failure scenarios/bottlenecks

What if same user tries to book the same slot two times, this can be handled with idempotency.

Network failure in the downstream can be handled with retry mechanism.

Future improvements

• Develop advanced algorithm to suggest user rooms based on their filter criteria
• Show floor map with the booked room highlighted.