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

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

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

POST locations --> add a new location

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

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 2db instances - one for reads and one for writes

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

We can have 2 APIs to scale - APIs will be stateless so we can autoscale as many as we need to serve traffic.