System requirements

Functional:

• Administrators can manage the inventory of conference rooms. Conference rooms has name, location (building/floor), capacity, video/audio equipment, options, video link, etc.
• Users can browse and search conference rooms by time, their location, by building/floor, and filter by capacity.
• User can book conference rooms. Once booked, all meeting participants gets an email with link to the conference room video.
• User can update or cancel conference room booking.
• Out of scope:
  • Admin can block out certain conference rooms and give management rights to a certain group.

Non-Functional:

• Strong consistency when booking rooms: conference rooms cannot be double booked.
• High availability when searching for rooms (99.95%)
• Low latency: browsing/searching for rooms < 500ms. Booking rooms < 2 sec.
• Scale: support up to 100k conference rooms, 1M DAU, 2M bookings per day
• Out of scope
  • Security: ensure only meeting organizers can manager booking
  • Support private meetings

Capacity estimation

Room data: assuming 1k of metadata for each room, total data is 100k * 1k = 100Mb

Request volume:

• Bookings: 2M / 86400 ~= 20 qps
• Assume browsing is 10x the traffic ~= 200 qps

API design

// Manage room inventory

POST /rooms -> Room

{

id, //output

name,

buildingId,

floor,

address,

lat, // output

long, // output

capacity,

videoLink,

status, // output

...

}

GET /rooms/ -> Room

DELETE / PATCH

// Find rooms

GET /rooms?lat={}&long={}&buildiingId={}&floor={}&capacity={}&time_start={}&time_end={}& -> Room[]

// Reserve room

POST /reservations -> Reservation

{

id, // output

owner, // output. Owner is the authenticated user

participants,

timeStart,

timeEnd,

}

// Manage reservations

GET /reservations/ -> Reservation

PATCH / DELETE

Database design

// User table is omitted

// Building table is omitted

Room table (100Mb)

• id (PK)
• name
• buildingId (FK into building table)
• floor
• address
• lat
• long
• capacity
• videoLink
• status // available | reserved | maintenance | deleted
• ...

Reservations

• id
• ownerId (FK into user table)
• timeStart
• timeEnd
• state // created | cancelled

We will use a relational database for its strong consistency.

Reservations: per day 2M *100b = 200Mb. Yearly growth is 200Mb * 365 = 70Gb.

Both tables are very small and can be hosted on a single instance of PostgreSql.

In addition, since the room table is very small, we enable full text index on name and address, and geo index on lat & long. Floor, capacity and status are also indexed.

For reservation table, we index timeStart and timeEnd.

High-level design

Gateway sits in between client and other services to act as load balancer, SSL termination, authentication, rate limiter, etc.

Room service handles room management and search requests.

Reservation service handles reservations.

Both services talk to the tables int the same database.

Request flows

Room management (using room creation as an example):

1. Admin client sends a create room request to Room service via Gateway.
2. Room service validates the request, then inserts the room as a row in Room table.

For an update or delete request, reservations may need to be changed.

• For example, if a room status is set to not_bookable, or room is gone. In this case room service looks for all affected, current reservations, and sets their status to "unconfirmed".
• We could implement something that notifies the users when such changes happens. In this case, we introduce a job service and queue. Room service puts a message indicating that a room should be taken offline. The job service picks up the message and updates reservations and send emails asynchronously.

For a room search request

• The client should send in the query parameters, such as start/end time, user's current location (this will be used to perform vicinity search). The Room service constructs a SQL query (using full text index, geo-spatial index if it is part of the query), then sort the results and return to client.

Reservation flow:

• Client sends a reservation request to Reservation service via gateway.
• Reservation service validates the request (e.g. the room should be online, no other reservations exists for that room), then adds the reservation to the reservation table, and return success.
• After the room is booked, room service enqueues a message on the job queue. The job service picks up the message and sends email to meeting participants asynchronously.
• If reservation fails, it should respond with status, and the reason.

Detailed component design

Reservation:

• We need to ensure strong consistency of reservations. If there are 2 concurrent reservations, only one should succeed.
• Since the chance of conflict is low, we choose optimistic locking instead of pessimistic locking.
• When making the reservation, we lock the row of the room. Inside the transaction we check if the room is still available, and if so, update the room to reserved and add the reservation row in one transaction.

Caching

• To handle 200 qps of traffic of browsing, we probably don't need to cache or shard the database, and let the database handle the traffic.
• If database load becomes a problem, we can put a redis cache in front of the database.

Cleanup:

• In the current design we store all reservations history. We should choose a retention limit, where a background process can prune the database for old reservations. If needed we can store the old reservations in cold storage to keep a record.

Trade offs/Tech choices

Database:

• Since data volume is low, we can use a single database instance with replicas. Sharding is probably an overkill for this use case.
• To support searching, we could leverage ElasticSearch. Again, the data and request volume doesn't compel us to do introduce the extra complexity.

Failure scenarios/bottlenecks

Room service, reservation service and job service are stateless and can be horizontally scaled for high availability.

For job queue, we can choose a managed queue (like SQS) or Kafka. The message volume is not high so we probably don't need extra partitioning.

For the database, we should enable high availability mode (having standbys with replication, read replicas)

Traffic spike:

• Implement proper monitoring, dynamic scaling
• Backpressure, exponential backoff on the client side

Future improvements

• Support room reservations that are managed by a security group rather than by anyone in the organization
• Auto-release rooms if the room is not used within the first 10 minutes of the reservation
• Automatically suggest rooms