Requirements

Functional Requirements:

• Allow employees to browse for rooms by their needs (eg: Capacity, equipment availability, timing etc)
• Allow employees to book the rooms for the selected time.
• Allow employees to modify their bookings i.e update time, cancel etc
• Gate entering room during booking.
• User recieves notifications for booking confirmation, booking updated, booking cancelled.
• Single bookings - Employees should not be able to book multiple room for at the same time, and same room cannot be booked by multiple employees.

Scale Estimation:

• Various organizations
• 1M users,
• ~10K daily bookings.
• Read heavy workload

Non-Functional Requirements:

• Highly Available - System should not fail when employee is browsing or booking
• Highly Scalable - Sysytem should be easily scalable to handle higher traffics and new organizations onboarding.
• Low Latency - System should be quick and efficient when employee is browsing rooms and booking rooms.

API Design

Organization

Id

Employees

Rooms

Employees

Id

EmpId,

Email

OrgId

Status => Active, InActive

Rooms

Id

Capacity

OrgId,

Type, => Lookup (eg, conference, auditorium etc)

Equipment => Lookup

Id

Name

Code

RoomEquipment

Id

RoomId

EquipmentId

Booking

Id,

EmpId,

OrgId,

RoomId,

StartDate,

EndDate,

Status

Status:

POST /find-rooms => find available rooms

req - {

filters : {

startDate,

endDate,

roomType,

Capacity,

Equipments

}

res - {

List

}

POST /booking => create room booking

req - {

roomId,

orgId,

EmpId,

StartDate,

EndDate

}

res - {

roomId

}

GET /booking/ {booking_id}

res - {BookingObject}

PUT /booking

req - {

status,

startDate,

endDate

]

Async background job - Scans for upcoming reservations in next 30 mins and triggers Reminder Event

High-Level Design

API Gateway

Acts as the entry point for all client requests.

Responsibilities:

• Authentication (if required)
• Rate limiting - using token bucket per API key to prevent abuse and control traffic.
• Request routing

Load Balancer

Distributes traffic across multiple instances of the Read and Write services to improve scalability and availability.

Booking Service

• Responsible for:
  • Creating bookings
  • Updating bookings
  • Cancelling bookings
  • Ensures no double booking or overlapping bookings for the same room.
  • Publishing all booking events to message queue

Availabity Service

• Responsible for:
  • Get bookings
  • Fetch available rooms via filters i.e. Capacity, Equipments, timing etc

Notification Service:

• Responsbile for:
  • Subscrining to events: BookingCreated, BookingUpdated, BookingCancelled, UpcomingBooking
  • Proceses the event and sends the notification to the employee email fetched from DB and sending the email event to Twillio to send out notifications.
  • When booking created, it publishes a delayed message to nessage queue using booking start time i.e. 30 mins before the start time to handle reminder for upcoming booking

MessageQueue:

• Acts as an event bus for all notification related event.
• Implements the DLQ strategy to ensure no message is lost when dependent services are down

Twillio:

• Third party email sending tool.
• Notificaiton service calls the Twillio API to sent out the notification to the user as well saves the notification in DB.
• Notificaiton service owns the notification message body/ to/ from etc, twillio only handles the delivery of the message, it acts as a External delivery provider between our system and Employee.

Redis

• We will cache room metadata, like capacity, equipment, etc, this rarely changes so its safe to cahce,.
• We will use long TTL like hours or days.
• This helps whenever room data is needed which is almost for every flow, espciallty when we are looking for available rooms.
• In case when Redis is down or cache service fails, we will fallback to DB to fetch the data.

PostreSQL

• Source of truth of all data, including bookings, employee data, org data, room data, and notifications sent.

Detailed Component Design

We will now deep dive into the following:

1) Ensure no double bookings or overlap bookings

• To ensure no double bookings we will use row-locking using Select For Update. The flow would be:
  • Employee A requests to book room 22.
  • Requests goes to booking service.
  • Booking service first does validation that employee does not have any other booking for the same time, if employee has then the request is rejectd there only.
  • Booking service then fetches the room in request to be booked:

Select * From Room

where RoomId = 22

For Update;

• • This locks the Room 22 row record.
  • After lacquire lock, we perform an overlap check:

• • If record exists then release lock and reject booking to allow others to book room22.
  • But lets asusme, no records exists.
  • While Employee A's request is processing Employee B also requests to book room 22 at the same time.
  • Request goes to booking service -> booking service does employee validation.
  • Booking service tries to fetch room record but due to row-lock, user B request has to wait.
  • User A completes its request and books the room 22.
  • User A 's lock on row is released.
  • User B now acquires the lock
  • Booking Service performs the overlap check again.
  • Sees room is no lonver avialable and thus request is sent back with failure.
• This locking strategy works here because it's simple and guarantees correctness. The downside is reduced concurrency since even non-overlapping bookings must wait. Given our scale of ~10K bookings/day, I believe this tradeoff is acceptable. If booking volume increased significantly, I would explore more granular locking strategies or database-level interval constraints.
• To ensure no overlap bookings are done:
  • Booking service before creating a booking, validates availalibuty of the room, this ensures the room Employee is trying to book is fully avialable for the requested time.
  • If its only partially aviable the request is rejected

2) Notification Serivce / Message Queue:

• How do we ensure Messages that are published to message queue are not lost when depended services are down, this covers Notification service and External delivery provider, i.e. Twilio.
  • For this, we will use DLQ.
  • The message will be retired 5 times, if after 5th attemp the message still fails, the message is moved to DLQ.
  • When a messages hit DLQ, an alert is sent out for further investigation
  • Messages in DLQ could be investigatged afterwards and could be retried for successful delivery.
• How do we ensure when message queue receive duplicate messages, those messages are not processed twice
  • For this, the approach we could take is have Consumer store all processed eventIds in redis with TTL of 7 days, , but the downside of choosing redis is that if Redis ever goes down or crashes, we will loose all processed ids which could result in users recieving duplicate notifications. However, the chance of being redis down and message queue gets duplicate messages are very low, and even if this happen the system accepts the tradeoff of employee reciveing multiple notifications as this does not impact any bookings or critical system usage.
  • So, When consumer processes a message:
    • Checks redis -> if event id exists -> skip
    • If redis down -> skip checking eventIds
    • if event id doese not exist -> message gets processed

3) Cache invalidation strategies:

• In Redis, we are only storing Room metadata which is not changed often.
• However, we will use Write-through policy whenver the room metadata updates, meaning we will update Redis and then update DB immediately.
• We will also use a TTL of 24hr, so every 24hr cache refreshses.