Requirements

Functional Requirements:

• Allow users to browse and search available conference rooms by time slot, capacity, location (building/floor), and equipment (projector, video).
• Enable users to create, update, and cancel room bookings, including room, time, organizer, and optionally participants.
• Prevent double-booking of rooms by ensuring that concurrent booking attempts are serialized.
• Send users email or push notifications when a booking is confirmed, updated, or cancelled, and send reminder notifications before the meeting starts.
• Support user authentication and authorization with role-based access controls: regular users can book rooms, admins can manage room inventory and settings.

Non-Functional Requirements:

• Reliability and accuracy of a data.
• Strong consistency as if one user reserves the room then the other needs to see it booked. such as preventing double-booking through database transactions or locking mechanisms.
• High availability (system responds in max. 2 seconds). expected availability percentage (e.g., 99.9%+)
• Low latency

Capacity Estimation

There are arount 100

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design

Admin Panel with restricted privilidges:

1) Creating rooms:

POST: /api/rooms

2) Updating rooms:

PUT: /api/rooms/:roomId

3) Deleting rooms:

DELETE: /api/rooms/:roomId

User:

1) Searching rooms:

GET: /api/rooms

Params: start_from, end_to, equipments, capacity

2) Book room:

POST: /api/rooms/:roomid

Params: start_from, end_to

3) Update/Cancel room:

PUT: /api/rooms/:roomid

return 200 or already booked

High-Level Design

Client is connecting via API Gateway (which handles authentication and rate conditions) which than connects to a backend server which handles the operations. Internally it uses Booking Service for reserving rooms (transactions), Availability Service for checking if possible and Notification service once it is done (this is using queue). Cache is being used in Availalability Service when quering data.

This data in Cache is being removed/updated (invalidated) every time some booking occurs to make it consistent.

Database Design

This should be Postgresql that will handle easily 50 writes/reads per second which is fine for this case. And this should as well use the feature of Posgresql that handles constraints automatically on the DB level.

Cache (Redis, NoSQL key-value) is being used for storing availabilities - this is being asked first and if the data is not there, then database.

Database should have tables like:

Rooms (Id, Name, Building, Floor, Equipment, Capacity), Bookings (Id, From, To, User, DateTime Reserved), Users (UserId, Email)

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.

Availability Service is using Redis to check (<10ms), if the entry is there it returns that it is available or not. If the entry is not there it is querying Posgresql DB (100-120ms). Each time the Booking service reserves or cancels reservation for the room, Cache is being updated by deleting the entry.

Notification Service simply uses some queue (SNS) to send confirmation to the user. If this fails, the users will be updated later.

Booking Service checks first if can enter data. If not, returns 409, if yes, than low level lock and then sends insert to Posgresql and once returning 200, updates cache. The lock is done on low level but also the DB ensures it itself on conditions that must be met.