Practice/LinkedIn/Design a Calendar System

Design a Calendar System

System DesignMust

Problem Statement

Design a calendar system that allows users to register, manage their schedules, and view other people's availability and free/busy times. The system must support time-range queries, recurring events, permissions (free/busy vs full event details), and multi-device experiences.

The challenge is modeling time-based data, handling high-read workloads for availability queries, managing concurrency to avoid double-booking, and supporting real-time updates. You must reason about indexing windows of time, recurrence and time zones, privacy boundaries, and the trade-offs between correctness and latency at scale.

Key Requirements

Functional

User management -- users register, sign in, and manage their profile including working hours and timezone
Event lifecycle -- users create, edit, and delete events (including recurring events and exceptions) on their calendars
Privacy controls -- users control calendar sharing and privacy (free/busy only vs full event details) for individuals and groups
Availability queries -- users view other people's availability over a selected time window and find mutually available slots

Non-Functional

Scalability -- support millions of users with tens of events per user per day; handle burst traffic during business hours
Reliability -- never lose event mutations; availability queries reflect latest state within seconds
Latency -- day/week/month calendar views load in under 300ms; group free/busy queries return in under 500ms
Consistency -- strong consistency for event creation to prevent double-booking shared resources; eventual consistency for cross-device sync

Interview Reports from Hello Interview

9 reports from candidates. Most recently asked at LinkedIn in Early January 2026.

Also commonly asked at: Microsoft.

What Interviewers Focus On

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

1. Free/Busy Query Performance

Checking availability across multiple participants requires efficient time-range queries. Naive approaches scanning all events will not scale.

Hints to consider:

Index events by (user_id, start_time) for efficient range scans within queried windows
Precompute or cache per-user busy intervals (sorted list of occupied time ranges) in Redis
For group availability, query each participant's busy times in parallel and compute the intersection
Consider bitmap representations (one bit per 15-minute slot for the current week) for ultra-fast availability merging

2. Recurrence and Timezone Handling

Recurring events and timezone transitions (DST) are common sources of bugs. Interviewers expect a robust approach.

Hints to consider:

Store recurring events as a pattern (RRULE) with exceptions stored separately, not as fully materialized instances
Compute occurrences on-the-fly within the queried time range using the recurrence pattern
Store all times in UTC with the creator's IANA timezone identifier for correct DST handling
Handle recurrence exceptions (single occurrence cancellations, modifications) as override records linked to the series

3. Concurrency Control for Shared Resources

Concurrent event creation for meeting rooms or overlapping invitations can cause double-bookings.

Hints to consider:

Use optimistic concurrency with conditional writes (compare-and-swap on event version) to prevent conflicting updates
For room booking, check availability atomically within a transaction before creating the event
Make RSVP and event edit operations idempotent to handle network retries safely
Design conflict resolution that presents options to the user rather than silently overwriting

4. Real-Time Sync Across Devices

Calendar changes must be visible immediately on all connected devices for the same user and collaborators.

Hints to consider:

Use WebSocket/SSE connections per active user to push event mutations in real time
Publish event changes to Kafka for reliable fan-out to notification, search indexing, and cache invalidation consumers
Implement change streams from the database to trigger cache invalidation for affected users' calendar views
Support offline mode on mobile with conflict resolution when the device reconnects

Practice/LinkedIn/Design a Calendar System

Design a Calendar System

System DesignMust

Problem Statement

Key Requirements

Functional

User management -- users register, sign in, and manage their profile including working hours and timezone
Event lifecycle -- users create, edit, and delete events (including recurring events and exceptions) on their calendars
Privacy controls -- users control calendar sharing and privacy (free/busy only vs full event details) for individuals and groups
Availability queries -- users view other people's availability over a selected time window and find mutually available slots

Non-Functional

Scalability -- support millions of users with tens of events per user per day; handle burst traffic during business hours
Reliability -- never lose event mutations; availability queries reflect latest state within seconds
Latency -- day/week/month calendar views load in under 300ms; group free/busy queries return in under 500ms
Consistency -- strong consistency for event creation to prevent double-booking shared resources; eventual consistency for cross-device sync

Interview Reports from Hello Interview

9 reports from candidates. Most recently asked at LinkedIn in Early January 2026.

Also commonly asked at: Microsoft.

What Interviewers Focus On

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

1. Free/Busy Query Performance

Checking availability across multiple participants requires efficient time-range queries. Naive approaches scanning all events will not scale.

Hints to consider:

Index events by (user_id, start_time) for efficient range scans within queried windows
Precompute or cache per-user busy intervals (sorted list of occupied time ranges) in Redis
For group availability, query each participant's busy times in parallel and compute the intersection
Consider bitmap representations (one bit per 15-minute slot for the current week) for ultra-fast availability merging

2. Recurrence and Timezone Handling

Recurring events and timezone transitions (DST) are common sources of bugs. Interviewers expect a robust approach.

Hints to consider:

Store recurring events as a pattern (RRULE) with exceptions stored separately, not as fully materialized instances
Compute occurrences on-the-fly within the queried time range using the recurrence pattern
Store all times in UTC with the creator's IANA timezone identifier for correct DST handling
Handle recurrence exceptions (single occurrence cancellations, modifications) as override records linked to the series

3. Concurrency Control for Shared Resources

Concurrent event creation for meeting rooms or overlapping invitations can cause double-bookings.

Hints to consider:

Use optimistic concurrency with conditional writes (compare-and-swap on event version) to prevent conflicting updates
For room booking, check availability atomically within a transaction before creating the event
Make RSVP and event edit operations idempotent to handle network retries safely
Design conflict resolution that presents options to the user rather than silently overwriting

4. Real-Time Sync Across Devices

Calendar changes must be visible immediately on all connected devices for the same user and collaborators.

Hints to consider:

Use WebSocket/SSE connections per active user to push event mutations in real time
Publish event changes to Kafka for reliable fan-out to notification, search indexing, and cache invalidation consumers
Implement change streams from the database to trigger cache invalidation for affected users' calendar views
Support offline mode on mobile with conflict resolution when the device reconnects