Requirements

Functional Requirements:

List the key functional requirements for the system (Ask the AI for hints if stuck)...

• Users should be able to book a conference room via online interface or via portal outside of that room
• Users should be able to view available rooms for a given time period and also availability of a given room for the future time period.
• Users should be able to view their upcoming bookings
• Admins should be able to modify/cancel any booking
• Users will receive notification upon successful booking

Non-Functional Requirements:

List the key non-functional requirements (performance, scalability, reliability, etc.)...

• Room should be booked in couple of seconds
• We need a strong consistency for room booking; no 2 users should be allowed to book same room at the same time.
• Their should be minimal latency(few 100ms) for viewing availability of room for the upcoming time period, as well as for viewing available rooms for the given time period.

Estimations:

1000 office locations

each office location has 100 rooms

so 100K rooms total

100K to 1M employee total

booking allowed for next 1 to 3 year

approx 1000 days * 1000 minutes each day = 1M minutes * 100K = 100B room minutes of resources

at peak time:

mostly people from same office will book a room, each office has 1K to 10K employee at the max

not more than 100 to 500 will try to book the same room at a given time and not all of the requests will reach at the very same time(practically for this less count)

This is not a very large load for a server or DB to handle

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

1) To book a room for a given time period:

POST booking.com/v1/room/book

input:

roomId

userDetails

timePeriod

output: booking confirmation with a booking ID upon success

2) To view availability of room(s) for a given time period

GET booking.com/v1/room/availability?startTime=20250404103000&endTime=20250404110000

output:

boolean: true/false (or array of booleans for multiple rooms)

3) To view bookings of room(s) for a given time period

GET booking.com/v1/room/bookings?startTime=t1&endTime=t2

output:

array of bookings

each booking has:

startTime

endTime

• Canceling a Booking:

DELETE booking.com/v1/room/book/{bookingId}

• Viewing User Profile:

GET booking.com/v1/user/profile/{userId}

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.

• Its not very common to change bookings/cancel bookings every few minutes; Also, availability of a room for a given day can be easily represented as 1000 bits. If we use 1 long long int or 64bit int for 1 hour(60 min) then we need approx 1440 or ~1500 such big integers.
• so 1500 * 8 = 12000 bytes for 1 room; so 100 rooms will need just 1200KB of memory cache, that's a very less data to hold in memory.
• We will update this cache when new booking happens or any change in booking happens.
• Otherwise we will rely on DB call for this.
• So availability related data can be easily fetched from memory and it will be very fast call as well(since its served from memory)
• We can maintain multiple such in memory cache or copies of data so that even if multiple people are just viewing the availability of rooms, we will never have scalability problem.
• So till this point we have addressed 2nd and 3rd API with low latency(both need only availability knowledge)
• For the first API we have 2 approaches:

1. Do primary operation in memory and if booking is successful then also push this to even stream which can eventually synchronize DB for durability.
2. Do this operation directly in DB.

1st option is preferred for cases where we need to support lot of concurrent operations with low latency.

2nd option is preferred for simplicity and comparatively less load.

Depending on our use case we can choose one.

• For our specific metric we can easily go with 2nd option since DBs of modern world easily support 1000s of concurrent connections.

• We can migrate to 1st option as our scale increases.