System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

• book a conference room for requested time if it is available
• change a reservation by booking another room or time
• cancel a booked conference room
• view all rooms available in a building, on a floor
• view all bookings in a room for a given day

Non-Functional:

List non-functional requirements for the system...

• consistent
• highly available
• scalable - allows adding/removing rooms easily

Capacity estimation

Estimate the scale of the system you are going to design...

Number of rooms available rooms = 100 approx

Number of users = 1500 approx

Max num of bookings per day per room (considering 30 min meetings with 8 hour workday) = 16

Max total number of bookings per day = 16 * 100 = 1600

Total number of users per day = 150 approx, estimating that 1/10th of the total employees reserve a room

Number of concurrent requests to the system = 5 max. Conference room booking system is not used concurrently.

Read and write volumes are not high. Amount of data stored is also not high as stale data can be moved to tape backup.

API design

Define what APIs are expected from the system...

• Get all available rooms

GET https:///rooms/building=x&floor=y

Returns:

{

room id:

room name:

capacity:

}

• Show a particular room

GET https:///rooms?id=x

Returns:

{

room name:

location:

capacity:

}

• Reserve a room for a time slot

POST https:///reserve?roomId=x&start=t1&end=t2

Returns:

201 OK with reservationId for successful response

40x if room is unavailable

• Change a reservation

PUT https:///update?reservationId=x

{

startTime:

endTime:

roomId:

}

Returns:

201 OK if successful

40x if there is a conflict

• Cancel a reservation

DELETE https:///cancel?reservationId=x

Returns:

200 OK if successful

• View all reservations for a room for given day

GET https:///reservations?roomId=x&date=d

Returns JSON array:

{

startTime:

endTime:

reservedBy:

},

{...},

{...}

}

Admin APIs

===========

Add or Remove a room(maintenance or other reasons)

• Add a room

POST https:///room

{

name:

location:

capacity:

status:

}

Returns: 201 Ok with roomId

• Delete a room

DELETE https:///room?id=x

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

As the amount of data is low and read/write load is less, SQL DB like MySQL, Postgres, Oracle etc. are suitable.

Transaction semantics are required and data schema is well-defined so SQL DB must be used.

Rooms DB

==========

Room Id -- Primary Key

Name

Location

Capacity

Status -- available/offline etc. set by admins

Room Availability DB (used for conflict detection for concurrent overlapping booking)

==============

Room Id (Primary Key)

Start

End

ReservationId

Reservation DB

============

Reservation Id

Room Id

Date

Start

End

Reserved By

• When reservation is made, Room Availability and Reservation tables are updated atomically. Room Availability table detects conflict due to concurrent overlapping booking.

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

• User: Employee trying to book/modify or cancel a room. OR admin user trying to update the Rooms
• Role-based Auth: Authenticates the API/s based on user role
• Reservation Service: Handles all apis related to making/modifying/cancelling a reservation
• Room Service: Handles all apis related to fetching rooms info or updating Rooms DB
• Database: SQL Database

Reservation and Room Service can be microservices for scalability

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

• User: Employee trying to book/modify or cancel a room. OR admin user trying to update the Rooms
• Role-based Auth: Authenticates the API/s based on user role
• Reservation Service: Handles all apis related to making/modifying/cancelling a reservation
• Room Service: Handles all apis related to fetching rooms info or updating Rooms DB
• Database: SQL Database

Reservation and Room Service can be microservices for scalability

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Database design and conflict resolution is an important aspect of this system.

Optimistic Concurrency Control is used in this database. This means that conflicting reservations are rejected at commit time. If 2 requests try to book a room concurrently and the times overlap, the 1st request succeeds and the 2nd fails at commit time. The Room Availability DB is not locked(pessimistic concurrency control) when the 1st request tries to access it.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Optimistic Concurrency Control allows only 1 request out of all conflicting requests to go through at a time. It also does not avoid conflict.

However, this approach is used for following reasons:

• Locking the DB using Pessimistic Concurrency Control makes user APIs slow
• This system does not have high concurrency so allowing 1 request out of all conflicting requests to succeed at a time is acceptable.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

• Central booking system has a single point of failure. Can have a monitoring system which brings up another instance in case of failures.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

• Integration with email system
• Intelligence to suggest rooms based on number of attendees so that other rooms are free for meetings with larger/smaller audience