Tiny System Design - Design a Google Calendar Like App with Recurring Events

#tinysystemdesign is a series of posts and articles that I intend to present a subset of a problem statement of a bigger application. The goal is not to design a full system but add enough components to make the problem statement under consideration ready for an MVP or POC. I will usually target the version 1 of the problem statement but considering the existing knowledge that we have in hand the v1 may be better than the original v1 when this knowledge and artifacts were not easily available. On the other hand, this could also be a crappy solution but enough information to whet your appetite to motivate you to dig more into this subject.

Through this series of articles, I also intend or make an attempt to take the complexity out of the system design topics.

I also believe system design should not be a

Now, please do note that building this system at scale involves a lot of moving parts and also multiple alternate strategies could be used.

I present here my process to approach these problem statement keeping the KISS (Keep It Simple, Stupid) principle in mind.

Problem Statement: Design a basic calendar system similar to Google Calendar, with a focus on handling recurring events. Your system should allow users to create, view, update, and delete events, with special attention to how recurring events are managed.

Key Features:

1. User registration and authentication.

2. Create single or recurring events.

3. View daily, weekly, or monthly schedules.

4. Update or delete specific occurrences of a recurring event or the entire series.

5. Efficiently handle and display recurring events based on different patterns (daily, weekly, monthly).

Bonus: Design the database schema and visualize the system's architecture.

Difficulty Level: Beginner to Intermediate

I will be providing certain hints, suggestions and guidelines. Let's make this a community initiative and post your thoughts, solutions.

However, do note to treat all responses with respects and let's not get into the debate that leads us nowhere.

The representative high level diagram is depicted below for quick reference.

HIGH LEVEL OVERVIEW

High-Level Overview:

1. User Interface (UI): A web or mobile interface where users can create, view, update, and delete events.

2. Backend Server: Processes requests from the UI, interacts with the database, and sends responses back to the UI.

3. Database: Stores user data, events, and other related information.

Database Design:

1. User Table: To store user information.

   UserID (Primary Key), Name, Email, Password (hashed)

2. Event Table: To store event details.

   EventID (Primary Key), UserID,(Foreignkey)Title,Description,StartDateTime,EndDateTime,Location, IsRecurring (Boolean)

3. RecurringEvent Table: To store details of recurring events.

   RecurringEventID (Primary Key), EventID (Foreign Key), RecurrenceType (Daily, Weekly, Monthly, etc.), EndType (Never, After N occurrences, On specific date), EndDate (if EndType is a specific date)Frequency (e.g., every 2 days, every 3 weeks)

Handling Recurring Events:

1. Creation:

   When a user creates a recurring event, an entry is made in the Event table with the flag set to true.Additional details about the recurrence pattern are stored in the RecurringEvent table.

2. Viewing:

   When displaying events, the system checks if an event is recurring.If it is, the system calculates all occurrences of that event based on the recurrence pattern and displays them.

3. Updating:

   If a user updates a specific occurrence of a recurring event, the system can either: a. Update only that specific occurrence. b. Update all future occurrences. c. Update all occurrences (past and future).Depending on the choice, the system might create a new separate event for the updated occurrence or update the original recurring event pattern.

4. Deletion:

   Similar to updating, when deleting a specific occurrence of a recurring event, the system can either:

   a. Delete only that specific occurrence.

   b. Delete all future occurrences.

   c. Delete all occurrences (past and future).

Scaling Considerations:

1. Database Sharding: As the number of users and events grows, the database can be sharded based on UserID to distribute the load.

2. Caching: Frequently accessed events can be cached to reduce database load.

3. Background Jobs: Calculating occurrences of recurring events can be CPU-intensive. This can be offloaded to background jobs, especially for events with a large number of occurrences.

A sample diagram using Remix/Next, Postgres, RabbitMQ, Redis.

Deployment Diagram (Simplistic view)

Security Better Practices

1. Whitelist IPs: Only the IP addresses of the Kubernetes nodes should be whitelisted to access the managed PostgreSQL service.

2. Connection Pooling: Consider using connection pooling to efficiently manage and share database connections among multiple application instances.

3. Private Connectivity: Use private IP addresses or VPC peering to connect to the managed database service to ensure security.

4. SSL/TLS: Always use SSL/TLS for encrypting data in transit between the Kubernetes nodes and the managed PostgreSQL service.

Inviting you all to share your thoughts, share your design idea, tech stack etc.

PS: I am putting my thoughts and initial ideas all the articles in #tinysystemdesign will be incrementally updated with more details.