System requirements

Functional:

• View own calendar or of specified user
• See available meeting rooms
• Create meeting invite (1 time & recurring)
• Cancel meeting
• Accept/decline meeting invite
• Get notified of meeting invite/accept

Non-Functional:

• Scalable to millions of users
• Highly available/reliable

Capacity estimation

10,000,000 users

1 meeting created per day per user

2 meetings accepted per day per user

Each persons calendar has 2 meetings per day on average

So 10,000,000 meetings created per day or ~100 meetings per second, ~200 meetings accepted per second

API design

User APIs

view_calendar(user_id, granularity)

granularity may be day/week/month - Returns calendar with available and busy time slots

available_meeting_rooms(office_id, start_time, end_time, num_attendees)

Returns list of available rooms (room_name, room_id)

reserve_room(room_id)

If a room cannot be reserved return 400 error, else return 200 and reservation_id

create_meeting(reservation_id, start_date, end_date, List)

Return meeting ID

create_recurring_meeting(reservation_id, meeting_schedule, List)

cancel_meeting(reservation_id, meeting_id)

Remove meeting from calendars of all attendees and free up the meeting room reservation

accept_meeting(meeting_id)

decline_meeting(meeting_id)

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

1. Load balancer - like Nginx/HAProxy
2. API server to handle incoming requests
3. Meeting room reservation manager
4. Calendar manager
5. Notification service
6. Calendar DB
7. Meeting room DB

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Request flows from the Load balancer that does user based partitioning so requests from same user goes to same API server.

To view a calendar for specified user, we use calendar manager, which talks to the calendar DB

To reserve meeting room, we ask the reservation manager which talks to the reservation DB.

Accept/decline meeting talks to calendar manager

Create and Cancel meeting APIs talk to both calendar manager and reservation manager since in both we need to update the calendar table and the meeting reservation table.

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

• Calendar DB can receive heavy load since we need to be able to view all the meetings as well as add meetings and remove meetings. If using NoSQL DB, we can scale well but may lose some consistency guarantees. We can use user_id as hash key and start_date_time as range key for easily retrieving meetings within a given range
• Reservation table that keeps meeting reservations has strong consistency requirements to prevent multiple people from double booking rooms, so we can use SQL DB. We can acquire a lock on the meeting room to prevent other users from reusing the same meeting room. Or we can use optimistic locking where we assume we can reserve a room by keeping track of existing state and if the state in the DB changes in the meantime we can fail the request
• Notifications service for meeting create/accept/decline/cancel can be handled asynchronously by pushing the event in an event queue (ex. Kafka). If notification fails it can be retried with exponential backoff.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

• Our system is eventually consistent, which means meeting once created may take a few seconds to propogate. However it is highly available.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

• We may have a large peak traffic with a huge volume of meetings created in a bursty fashion - to handle we can use autoscaling to scale up resources to handle increased load. We can spread traffic using consistent hashing on the user ID hashkey range.
• To ensure durability of the calendar invites we should use multi-region replication of the Calendar DB
• It's possible we may see a meeting room as available but when attempting to reserve it is already reserved. This can be a bad user experience. We can avoid it by offering only a subset of meeting rooms as available to a user, or asking user to use additional filters such as floor location.
• Since notifications are handled asynchronously via event queue, it's possible to have them be delivered to end user out of order, which can be confusing. For example a cancel meeting notification send before a meeting invite for the same meeting ID. We want to have causal consistency in the meeting notifications. So meeting notifications should be partitioned by meeting ID in the queue, and such that the notification worker always pick up the notifications in the right sequence.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?