System Design – Design Google Calendar

Google Calendar is like a special calendar that we can use on our computer or phone. We can use it to remember important things, like birthdays, appointments, and events. We can also set reminders to help us remember when something is coming up soon. We can also share our calendars with our family or friends. It’s like having our own special schedule that helps us keep track of everything that we need to do.

With Google Calendar, we can quickly schedule meetings and events and get reminders about upcoming activities, so we always know what’s next.

Requirements of the System:

Functional Requirements:

• Book an event: In a calendar, we are able to add an event with other people. It can be a single user or multiple users.
• Check availability of users: While we are scheduling an event before that if we can figure out in that particular time the person is available or not.
• Invite users to the meeting/event: The user should be able to invite other users to the meeting or event. The number of users invited for a scheduled meeting can be one or more than one.
• Request RSVP: Before posting an invite to the person we want to know if that particular user is already blocked or if he is available. So these types of responses can be handled by requesting RSVP.
• Meeting Reminders: Getting a notification before the time for a particular meeting with a particular person about the agenda and all those details would help prepare for the meeting beforehand.
• Modify the meeting /event: This includes making changes to an existing meeting or event that you have created or have been invited to.
• Cancel a meeting/event: This includes deleting or removing a meeting or event that you have created or have been invited to.
• Lookup for all meetings in the calendar: This includes viewing a list of all events that have been designated as meetings or events.
• View Calendar: This allows the user to see their scheduled events and appointments in a visual format which can be a monthly, weekly, or daily view, and it includes details such as the date, time, location, and description of each event.

Non-Functional Requirements:

• High availability: This means that users should be able to use Google Calendar whenever they need it, without experiencing any significant interruptions or downtime.
• Eventual Consistency: This means that sometimes changes made to an event might not show up for everyone right away, but eventually the changes will be applied and everyone’s calendar will show the same updated event.
• Low/minimum latency: This means that the application should respond quickly to your requests and updates, so you don’t have to wait for a long time to see your changes.
• Durable storage: The system should be durable enough to not lose any kind of user and meeting data.

Memory and Estimations of the System

Let’s start with the estimation and constraints because these things help us to make better design decisions that’s why we do estimations along with the requirement gathering.

Assumptions:

Let’s assume the system is designed for 100M users.

So, the number of concurrent users=100M

And out of all these users, 1/10 of the people are actually scheduling the event.

So, 1/10 post invites=10M

And assuming a particular person creates 5 events in a day.

So, 5 events/ user=50M invites per day

So, storage for 1 invite={ Meeting content +userId, invite list+date }

                                    = 1 KB

Therefore, the Total storage=1KB*50M

                                            = 50,000,000KB

                                            = 50GB/day

Storage for 1 year = 50*365

                              = 20TB/year

Data Flow Diagram

Data flow for a particular user viewing the Calendar

data flow for the user viewing the Calendar

1. The user opens the Google Calendar app on their device.

2. The device sends an HTTP request to the Google server to authenticate the user and establish a secure connection.

3. The Google server verifies the user’s credentials and sends an HTTP response to the user’s device.

4. The device sends an HTTP request to the Google server to retrieve the user’s calendar data.

5. The Google server retrieves the user’s calendar data from the Google Calendar database.

6. The device displays the calendar data to the user through an interface.

7. The user interacts with the calendar by adding, modifying, or deleting events or changing settings.

8. The Google server processes the requests and updates the user’s calendar data in the Google Calendar database.

data flow diagram of the entire system

data flow diagram of the entire system

1. The user creates an event in their Google Calendar by providing event details such as the event name, date, time, and location.

2. The event data is stored in the user’s Google Calendar account, which is hosted on Google’s servers.

3. User invites attendees: If the event has attendees, the user can send out invitations to those attendees using their email addresses or by sharing a link to the event.

4. Attendees respond to the invitation: The attendees receive the invitation and can choose to accept, decline, or tentatively accept the invitation. Their responses are recorded in the event data.

5. Event reminders: If the user has set reminders for the event, these reminders are triggered at the appropriate times, based on the user’s preferences.

6. Event notifications: If the user has set notifications for the event, these notifications are sent to the user’s devices at the appropriate times, based on the user’s preferences.

7. Event updates: If the user makes changes to the event, such as changing the date or time, these updates are synchronized across all devices and attendees are notified of the changes.

8. Event deletion: If the user deletes the event, it is removed from their Google Calendar account and attendees are notified that the event has been canceled.            

Database schema and design

We would have the following tables to work along:

Database Schema Design

It is basically about understanding the requirement from a functional perspective and deciding how we are going to utilize the database and how are we going to design it.

While our data model seems quite relational, we don’t necessarily need to store everything in a single database, as this can limit our scalability and quickly become a bottleneck.

We will split the data between different services each having ownership over a particular table. Then we can use a relational database such as PostgreSQL or a distributed NoSQL database such as Apache Cassandra for our use case.

API design of the system

Let us do a basic API design for our services:

1. Display info for each user.

@GET /api/users/{userId}

For Scheduled Meetings or Events

2. Get meetings for the user for the current week

@GET /api/users/{userId}/meetings
{
     date: currentDate,
     days: 7
}

3. Creating the meeting Event

@POST /api/users/{userId}/meetings
{
     startTime: anyStartTime,
     endTime: anyEndTime,
     “users”: [“abc@gmail.com”,”xyz@gmail.com”],
     “subject”: “Important Meeting”,
     “meetingBody”: “Let’s have a stand-up”
}

4. Updating a meeting Event

PUT /api/users/{userId}/meetings/{meetingId}
{
   startTime: anyStartTime,
   endTime: anyEndTime,,
   “users”: [“abc@gmail.com”, “xyz@gmail.com”],
   “subject” : “Meeting Cancelled”,
   “meetingBody”: “Let’s have a stand-up”
}

For Reminders

A reminder consists of:

• When to show the reminder, expressed minutes before the event starts time.
• The delivery method to use.

Reminders can be specified for whole calendars and for individual events. Users can set default reminders for each of their calendars; these defaults apply to all events within that calendar. However, users can also override these defaults for individual events, replacing them with a different set of reminders.

5. Setting up the default meeting reminder

“reminders“: {
  “useDefault“: false,
  # Overrides can be set if and only if useDefault is false.
  “overrides“: [
      {
        “method“: “reminderMethod”,
        “minutes“: “reminderMinutes”
      },
      # …
  ]
}

The delivery methods offered by the system are:

• Pop-up: These are supported on mobile platforms and on web clients.
• Email: Sent by the server.

High-Level Design of the System

Design for a particular user viewing the Calendar and the related events/meetings to that user

Design for a particular user viewing the Calendar and the related events/meetings to that user

Overall High-Level Design of the System

The high-level design of the system

Microservices Used

Meetings Microservice

Let’s have a look at how a user can create a meeting for a group of users:

• Validated POST request for a new meeting comes to the backend. After validation of each field, the backend makes a call to the Meetings microservice to create a meeting.
• This microservice makes an entry in the meetings table with all the details from the request body.
• For each user in the invitees’ list, add the entry for each user in the invites table.
• Send the list of invites to the Notification generation microservice to notify all users of the meeting info.

Notification Microservice

• This is very simple. It reads from the queue all the invites and sends a notification through email to the users.

Conclusion

In conclusion, designing a system like a Google Calendar needs careful consideration of various components and features which would be crucial to its functionality. The system must be scalable and flexible, allowing for easy integration with other applications and platforms. It should also be secure and reliable. 

Overall, a well-designed system for Google Calendar should provide users with a reliable and efficient tool for managing their daily schedules and events, while also should be allowing for easy collaboration and integration with other applications and platforms.