Requirements

Functional Requirements:

1. List of conference rooms, for each conference room, we need to know
   1. Schedule
   2. Details: Locations, number of people each room holds
2. Need to be able to reserve, change and cancel reservations
3. No double booking for a room
4. Notification - confirmation and reminders
5. Auth & Roles
   1. User login
   2. admins manage room
6. Usage reports for admins

Non-Functional Requirements:

1. Double booking
2. User friendly UI
3. Scale to 1M users
4. Scale to different locations/building
5. Allow to book different period of times 1hr - 30 min
6. Max time allowed for each room for a booking
7. features of each room - have a display...etc
8. Store history - so a user can rebook a room they previously booked
9. Low latency
10. High Availability
11. Concurrent requests

Capacity Estimation

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

1. 100K rooms, 1M DAU (daily active users),

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

GET locations --> get all buildings

GET locations/{location_id} --> get all details of a building

GET locations/{location_id}/rooms --> get all rooms in a building

GET locations/{location_id}/rooms/{room_id} --> get a rooms details

PUT locations/{location_id}/rooms/{room_id} --> update a reservation for a room (book or cancel based on body fields)

POST locations --> add a new location

POST locations/{location_id}/rooms --> add a new room in a location

POST admin --> to make changes to an entire building

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.

high level diagram updated

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

SQL --> Relational DB because all the items are related to each other

Table 1: Buildings --> building_id, address, admin_id

Table 2: Users --> user_id, role (admin, user), user_email, user_phone, building_id

Table 3: rooms --> room_id, building_id, capacity, features (whether a room has a big display...etc)., max_duration, location_within_the_building

Table 4: Reservations --> user_id, room_id, date, time, duration

Table 5: reservations_history --> user_id, room_id, date, time, duration, type (booked, cancelled).

Table 6: notifications_history --> user_id, room_id, notifaction_sent_time_date, type (email, push)

Table 7: notification_preferences --> user_id, email (true/false), push (true/false)

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.

Database can scale vertically for now. can have 1 db instances - one for writes. the cache can be used to make read only requests faster.

Cronjob queries DB every day at midnight, find all the reservations for that day and sends email notifications to the users. same with push notifications

APIs will be stateless so we can autoscale as many as we need to serve traffic.

A booking service where all POST API requests go

A checking service where all read api requests go

To ensure no one can double book, the booking service will hold a transaction on the db row. if another user attempts to book it, they won't be able to.

Reporting service to generate aggregate reports for usage by building - this is for admins only