Requirements

Functional Requirements:

• User is able to reserve room
  • Can only reserve room when room is available
• User can cancel reservation
• User can see what time rooms are booked to check for room availability

Non-Functional Requirements:

• Low latency when booking room
• High consistency to ensure no double booking

Metrics:

• 500 DAU
• 20 rooms
• peak of 200 bookings per hour - 3.33 bookings per second

Looking at the metrics, there wont be much pressure on the system - can definitely handle the load even during peak hours

API Design

API DESIGN:

Public endpoints:

GET:

See available time for room

/room/:roomID&:Date

• Queries reservations to see schedule of room for date

POST:

Reserve room

/room/reserve

{userID, roomID}

• Add to reservation table

POST:

Cancel reservation

/room/reserve

{userID, roomID}

• Remove from reservation table

High-Level Design

Core Entities:

Users

• First Name
• Last Name
• Phone Number
• UserID
• CreatedTime, Metadata...

Rooms

• RoomID
• Room Capacity

Reservations

• RoomID
• StartTime
• EndTime
• UserID
• UpdatedTime, Metadata...

Use a SQL database specifically in this case because of the strong relationships between core entities - using SQL also ensures ACID properties to keep system consistent

Detailed Component Design

Avoiding Double bookings:

When reserving for roomA for example, pessimistically lock roomA with a FOR UPDATE query and in the same transaction, try to make reservation