Practice/Microsoft/Design a Calendar System

Design a Calendar System

System DesignMust

Problem Statement

Build a calendar and scheduling platform where millions of users can manage personal and work calendars, coordinate meetings across teams, and check availability without revealing private event details. Users need to create one-time and recurring events, share calendars with granular permissions, and quickly find free slots when scheduling meetings with colleagues across different time zones. The system should handle thousands of events per user, support sub-second availability lookups for groups of 20+ people, and ensure that concurrent edits don't cause double-bookings or lost updates. Your design must balance strong consistency for writes (no one should be double-booked) with fast reads for availability checks, while respecting privacy controls that let users share only free/busy status rather than full event content.

Key Requirements

Functional

User authentication and profiles -- users register accounts, manage time zone preferences, and configure default working hours
Event creation and management -- users create, edit, and delete calendar events with support for recurring patterns, exceptions to recurrence rules, and reminders
Calendar sharing and permissions -- users control visibility per calendar or per event, including private (no one sees), free/busy only (time blocked but no details), or full details shared with specific people or groups
Availability queries -- users query free/busy status for individuals or groups over a specified time range to identify potential meeting slots
Multi-calendar views -- users overlay multiple calendars (personal, work, shared team calendars) in a unified interface

Non-Functional

Scalability -- support 100 million registered users with 50 million daily active users creating or updating 500 million events per day
Reliability -- ensure 99.9% uptime with no data loss; gracefully degrade availability queries under load rather than fail completely
Latency -- event creation completes in under 200ms; availability queries for groups up to 20 people return in under 500ms at p99
Consistency -- prevent double-bookings through strong consistency on writes; allow eventual consistency for non-critical updates like read receipts or attendance status

What Interviewers Focus On

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

1. Time-Based Indexing and Query Performance

Availability lookups require scanning potentially thousands of events across multiple users within a time window. Naive full-table scans or unoptimized joins will timeout when checking group availability. Interviewers want to see how you'll make these queries fast enough for interactive scheduling.

Hints to consider:

Partition event tables by user ID and time range to limit scan scope
Use composite indexes on (user_id, start_time, end_time) to accelerate range queries
Cache aggregated free/busy intervals per user in time buckets (e.g., 15-minute slots for the next 30 days) and invalidate on event changes
Consider precomputing or materializing busy periods for frequently queried users or rooms

2. Concurrency Control and Double-Booking Prevention

When two people simultaneously try to book the same conference room or update overlapping events, race conditions can cause double-bookings or lost updates. The system must serialize conflicting operations without sacrificing perceived responsiveness.

Hints to consider:

Use optimistic concurrency with version numbers or timestamps on events; retry on conflict
Implement conditional writes (compare-and-swap) when reserving shared resources like rooms
Apply row-level locks or SELECT FOR UPDATE only for the specific time slots being modified
Generate idempotency tokens client-side so duplicate submissions don't create duplicate events

3. Modeling Recurring Events and Time Zones

Storing every instance of a daily recurring meeting for a year wastes storage and makes bulk updates painful. Time zones and daylight saving transitions add complexity: a "9 AM Pacific" meeting must render correctly in Tokyo and adjust when clocks change.

Hints to consider:

Store recurrence rules (RRULE) and expand occurrences on-demand during queries rather than materializing every instance
Persist event times in UTC but store the original time zone so you can recalculate local times when DST rules change
Cache expanded instances for a rolling window (next 90 days) to balance query speed and storage
Handle recurrence exceptions (canceled or rescheduled instances) as separate override records linked to the parent event

4. Privacy Boundaries and Permission Models

Users must control whether others see full event details, only free/busy status, or nothing at all. Conference rooms and shared calendars introduce delegation and group permissions. The system needs efficient ACL checks without slowing down every query.

Hints to consider:

Store per-event or per-calendar ACLs separately and join only when detail access is required; for free/busy queries, skip detail retrieval entirely
Use role-based groups (admin, editor, viewer, free-busy-only) to simplify permission checks
Cache permission grants in Redis keyed by (requester_id, calendar_id) to avoid repeated database lookups
Return only time blocks (start/end) for free/busy queries; fetch event titles and descriptions only when the requester has detail permissions

5. Real-Time Synchronization Across Devices

When one user updates an event, all attendees and devices viewing that calendar should see the change within seconds. Polling is inefficient; push notifications and cache invalidation are essential for a modern calendar experience.

Hints to consider:

Publish event mutations to a message queue (Kafka topic) that triggers notifications to affected users via WebSocket or push channels
Invalidate cached free/busy intervals and query results when events change, using event streams to coordinate cache updates
Use WebSockets or Server-Sent Events for active web clients; send mobile push notifications for offline users
Track subscription lists (which users are subscribed to which calendars) to fan out updates only to relevant recipients

Practice/Microsoft/Design a Calendar System

Design a Calendar System

System DesignMust

Problem Statement

Key Requirements

Functional

User authentication and profiles -- users register accounts, manage time zone preferences, and configure default working hours
Event creation and management -- users create, edit, and delete calendar events with support for recurring patterns, exceptions to recurrence rules, and reminders
Calendar sharing and permissions -- users control visibility per calendar or per event, including private (no one sees), free/busy only (time blocked but no details), or full details shared with specific people or groups
Availability queries -- users query free/busy status for individuals or groups over a specified time range to identify potential meeting slots
Multi-calendar views -- users overlay multiple calendars (personal, work, shared team calendars) in a unified interface

Non-Functional

Scalability -- support 100 million registered users with 50 million daily active users creating or updating 500 million events per day
Reliability -- ensure 99.9% uptime with no data loss; gracefully degrade availability queries under load rather than fail completely
Latency -- event creation completes in under 200ms; availability queries for groups up to 20 people return in under 500ms at p99
Consistency -- prevent double-bookings through strong consistency on writes; allow eventual consistency for non-critical updates like read receipts or attendance status

What Interviewers Focus On

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

1. Time-Based Indexing and Query Performance

Hints to consider:

Partition event tables by user ID and time range to limit scan scope
Use composite indexes on (user_id, start_time, end_time) to accelerate range queries
Cache aggregated free/busy intervals per user in time buckets (e.g., 15-minute slots for the next 30 days) and invalidate on event changes
Consider precomputing or materializing busy periods for frequently queried users or rooms

2. Concurrency Control and Double-Booking Prevention

Hints to consider:

Use optimistic concurrency with version numbers or timestamps on events; retry on conflict
Implement conditional writes (compare-and-swap) when reserving shared resources like rooms
Apply row-level locks or SELECT FOR UPDATE only for the specific time slots being modified
Generate idempotency tokens client-side so duplicate submissions don't create duplicate events

3. Modeling Recurring Events and Time Zones

Hints to consider:

Store recurrence rules (RRULE) and expand occurrences on-demand during queries rather than materializing every instance
Persist event times in UTC but store the original time zone so you can recalculate local times when DST rules change
Cache expanded instances for a rolling window (next 90 days) to balance query speed and storage
Handle recurrence exceptions (canceled or rescheduled instances) as separate override records linked to the parent event

4. Privacy Boundaries and Permission Models

Hints to consider:

Store per-event or per-calendar ACLs separately and join only when detail access is required; for free/busy queries, skip detail retrieval entirely
Use role-based groups (admin, editor, viewer, free-busy-only) to simplify permission checks
Cache permission grants in Redis keyed by (requester_id, calendar_id) to avoid repeated database lookups
Return only time blocks (start/end) for free/busy queries; fetch event titles and descriptions only when the requester has detail permissions

5. Real-Time Synchronization Across Devices

Hints to consider:

Publish event mutations to a message queue (Kafka topic) that triggers notifications to affected users via WebSocket or push channels
Invalidate cached free/busy intervals and query results when events change, using event streams to coordinate cache updates
Use WebSockets or Server-Sent Events for active web clients; send mobile push notifications for offline users
Track subscription lists (which users are subscribed to which calendars) to fan out updates only to relevant recipients