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.