System Design: Designing a Calendar Application

Question

Design a calendar application where users can view and schedule meetings.

Background

This is quite an open-ended question, similar to the previous design question. However, this question does have a slightly more algorithmic and data structure-focused bend to it as we’ll see when we discuss the design. It’s important to be ready for these types of questions, particularly if you have a Computer Science or technical background.

Solution approach

We’ll follow the same approach as we did for the previous question:

• Define system requirements

  Before we begin any design we’ll spend a few minutes agreeing on the one to two primary use cases we’ll need to cover.

• System breakdown

  We’ll then diagram the key individual components of the system needed to address the one to two primary use cases.

• Dataflow discussion

  We’ll discuss the necessary data points the system will need to collect and how they flow through the system.

• Scaling the design

  We’ll talk about design choices and tradeoffs to ensure that the system scales.

• Capacity modeling

  We’ll estimate the request volume and data volume the system will need to handle for a given time period.

Sample answer

System requirements

We’ll focus on two primary use cases for this system:

View calendar

When the user opens the application, they can see current calendar entries (i.e. booked meetings). For now, we will assume only a single time zone for simplicity. The user can page through to see future calendar entries.

Book meetings

The user should be able to book meetings on other users’ calendars. Conflicts should be detected. We will assume that meetings can be set at the minute boundary (i.e. the shortest meeting is one minute).

Note
We will assume for now that other supporting functions such as authentication will not be in scope for this exercise, although it may be a useful followup to think through how these other requirements may be implemented.

System breakdown: View calendar

Dataflow discussion: View calendar

1. The Client Application will initiate a request to the server containing the user_id and a pagination_index to request the user’s calendar feed (i.e. an ordered list of meeting instances). The pagination_index will default to today’s date and will be used to tell the server the starting point for the calendar feed.

2. The request will be handled by a Load Balancer, which will forward it to an available instance of the Get Calendar Feed service. This service will be responsible for managing the user session and ensuring the user has the latest available calendar feed. Once the service receives this initial request, it will start an entry for the session in the Active Session key-value store. The key for this store will be the user_id and the value will be the current pagination_index and timestamp. We can extend this to include additional information over time if needed, but for now, this will suffice for our use case.

3. Generating a user’s entire calendar feed on the fly will be very expensive and time consuming. We need to pre-generate a partial feed in advance and retrieve the latest one when we receive the initial request from the user. We will therefore make the following design choices:

   • We will pre-generate two months of data in advance of when we will need it. If there are no active sessions, we will generate the feed daily based on the current date. If there is an active session, it will be generated based on the most recently received pagination_index.
   • We will have a Generate Calendar Feed service that will be responsible for generating the per-user calendar feed from the Calendar store. We will discuss the intricacies of the Calendar store in the second use case.
   • The Active Calendar store will be a warm key-value store of pre-generated calendar feeds. They key will be the user_id and the value will be an ordered list of meeting instances for the next two months.

4. As the user pages through the calendar, we need to ensure a smooth viewing experience. That means we need to continue to pre-generate the calendar feed as the user pages through their calendar. As the user pages through, we will send the current user_id and pagination_index to the server. The Get Calendar Feed service will update the Active Session store with the latest pagination_index and send a request to the Generate Calendar Feed service to inform it to pre-generate the necessary calendar feed and store it in the Active Calendar store - i.e. if the user is viewing month N, generate the feed for month N+3.
   
   The Get Calendar Feed service will also retrieve the latest feed from the Active Calendar store and send this down to the client - i.e. if the user is on month N, retrieve and send the feed for months N+1 and N+2.

System breakdown: Book meetings

For the second use case, there are two requirements we need to have:

1. We need to be able to view another person’s calendar.

2. We need to be able to write to that person’s calendar and detect conflicts.

For requirement #1, this is not a super complex problem: we can use the same infrastructure and components as the first use case (viewing our own calendar) with an added authorization check to make sure that we’re allowed to view that person’s calendar.

We’ll focus our discussion on the second requirement with special emphasis on conflict detection. This is where we can put our algorithms and data structure knowledge to good use.

The first key question we need to answer is how we want to store individual calendars in the Calendar store.

One option is to store each Calendar object as an unordered list of meeting instances. This is a simple to implement data structure and requires little complexity. However, detecting conflicts will be very slow - we will need to iterate over every meeting ...