Practice/Amazon/Design a Calendar App

Design a Calendar App

System DesignMust

Problem Statement

Design a calendar application like Google Calendar that allows users to create and manage meetings, send invitations to participants, handle invitation responses (accept/decline), and view free/busy availability. The system must feel instant across devices, keep everyone's view consistent, and handle tricky details like time zones, recurring meetings, and reminders.

Interviewers ask this to test your ability to model time-based data, manage workflow fanout (invitations and notifications), ensure consistency under concurrency, and deliver low-latency reads at scale. Expect to discuss read-heavy patterns for calendar views, real-time updates for RSVP changes, reliable background processing for invites and reminders, and edge cases like DST transitions and recurrence exceptions.

Key Requirements

Functional

• Event management -- users create, edit, and delete meetings with details like title, time, recurrence rules, and location
• Invitations -- users invite participants (internal or external) and send invitations with accept/decline response handling
• Availability -- users view their calendar and see free/busy overlays for selected participants to detect scheduling conflicts
• Notifications -- users respond to invitations and receive notifications and reminders across devices

Non-Functional

• Scalability -- support hundreds of millions of users with typical calendar views returning dozens to hundreds of events per query
• Reliability -- maintain 99.9% uptime for event creation and calendar views; zero lost events or invitations
• Latency -- calendar day/week/month views loading under 200ms, event creation under 500ms, RSVP updates reflected within seconds
• Consistency -- strong consistency for event mutations and RSVP status; eventual consistency for free/busy aggregation and reminder scheduling

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Data Modeling for Time-Based Queries

Calendar views are time-range queries that must be fast. Recurring events, time zones, and exceptions make the data model complex.

Hints to consider:

• Store all event times in UTC with the user's timezone as metadata, computing display times on the client side
• Model recurring events as a rule (RRULE) plus a set of exceptions, expanding instances on read rather than storing all occurrences
• Index events by (user_id, start_time) for efficient range queries that power day, week, and month views
• Use database partitioning by user_id to keep calendar queries scoped to a single partition for predictable performance

2. Invitation Fanout and Notification Workflow

Creating a meeting with many attendees triggers a workflow: persist the event, fan out invitations, send notifications, and schedule reminders.

Hints to consider:

• Decouple event creation from invitation delivery using an outbox pattern or durable queue to keep the write path fast
• Fan out invitations asynchronously through Kafka, with each invitation creating an attendee record and triggering notifications via push, email, or SMS
• Implement idempotent invitation processing so retries do not create duplicate attendee records or send duplicate notifications
• Design reminder scheduling using a distributed delay queue (Redis sorted sets or SQS) that fires notifications at the configured time before each event

3. Concurrency and RSVP Consistency

Multiple users may update the same event simultaneously, and RSVP responses must be consistently reflected across all participants' calendars.

Hints to consider:

• Use optimistic concurrency control with version numbers on event records to detect and resolve conflicting edits
• Process RSVP updates as conditional writes on the attendee record, publishing status-change events for real-time propagation
• Implement read-your-writes consistency for RSVP updates so the responding user sees their updated status immediately
• Handle concurrent RSVP and event-edit conflicts by rejecting stale updates and prompting the user to refresh

4. Time Zone and Recurrence Edge Cases

Time zones, DST transitions, and recurrence exceptions break naive implementations and are a frequent source of bugs.

Hints to consider:

• Store recurring event rules with the original timezone so DST transitions adjust the UTC time correctly for each occurrence
• Support recurrence exceptions (canceling a single occurrence, moving one instance) without modifying the base rule
• Handle all-day events separately from timed events since they have different timezone semantics
• Validate that free/busy queries correctly account for timezone differences between participants in different regions

Suggested Approach

Step 1: Clarify Requirements

Confirm scope with the interviewer. Ask about supported recurrence patterns (daily, weekly, monthly, custom), maximum attendees per event, whether external calendar integration (CalDAV, iCal) is in scope, and if room/resource booking is required. Clarify whether the system should handle video conferencing links or just scheduling. Establish reminder delivery channels and advance notice options.