Practice/LinkedIn/Design a Calendar App

Design a Calendar App

System DesignMust

Problem Statement

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

The architecture must handle read-heavy patterns for calendar views, real-time updates for RSVP/status changes, reliable background processing for invites and reminders, and edge cases that break naive designs (DST transitions, recurrence exceptions, idempotency).

Key Requirements

Functional

Meeting management -- users create, edit, and delete meetings with details like title, time, recurrence, and location
Invitation workflow -- users invite participants (internal or external) and send invitations via email or push notifications
Free/busy overlays -- users view their calendar and see free/busy overlays for selected participants to detect scheduling conflicts
Response handling -- users respond to invitations (accept/decline) and receive notifications and reminders across devices

Non-Functional

Scalability -- support millions of users with hundreds of millions of events; handle burst traffic during business hours
Reliability -- never lose an event creation or RSVP update; notifications must be delivered at least once
Latency -- calendar views load in under 300ms; real-time RSVP updates propagate within 2 seconds
Consistency -- strong consistency for event creation and RSVPs to prevent double-bookings; eventual consistency acceptable for notification delivery

Interview Reports from Hello Interview

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

Also commonly asked at: Amazon, Microsoft.

What Interviewers Focus On

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

1. Event Data Model and Time Handling

Calendar events have complex temporal properties including time zones, recurring patterns, and exceptions. Interviewers want to see a thoughtful data model.

Hints to consider:

Store event times in UTC with the creator's timezone for display; convert to each viewer's timezone at read time
Model recurring events with an RRULE pattern (RFC 5545) and store exceptions (cancellations, modifications) separately
Avoid materializing all occurrences of a recurring event; compute them on-the-fly within the queried time range
Handle DST transitions by using IANA timezone identifiers rather than fixed UTC offsets

2. Invitation Fan-Out and Notification Pipeline

Creating a meeting with many participants triggers a fan-out workflow. Interviewers expect this to be asynchronous.

Hints to consider:

Decouple event creation from invitation delivery using an outbox pattern or event-driven architecture
Publish an event_created message to Kafka; notification workers consume and send invites via email/push
Schedule reminders as delayed messages using Redis sorted sets or a job scheduler
Ensure idempotent invitation processing to handle retries without sending duplicate emails

3. Free/Busy Query Optimization

Checking availability across multiple participants requires efficient time-range queries. This is often the performance bottleneck.

Hints to consider:

Index events by (user_id, start_time) for efficient range scans within calendar view windows
Cache per-user busy intervals for the current week in Redis for fast overlap detection
For group availability, query each participant's busy times in parallel and compute intersection
Precompute free/busy bitmaps (one bit per 15-minute slot) for fast availability merging

4. Concurrency and Double-Booking Prevention

Concurrent event creation for shared resources (meeting rooms) or RSVP processing can cause conflicts.

Hints to consider:

Use optimistic concurrency control with version numbers on events; reject updates with stale versions
For shared resources, use conditional writes or distributed locks to prevent double-booking
Make RSVP updates idempotent using (event_id, user_id, response) as a unique constraint
Handle edit conflicts by showing the user a conflict resolution UI rather than silently overwriting

Practice/LinkedIn/Design a Calendar App

Design a Calendar App

System DesignMust

Problem Statement

Key Requirements

Functional

Meeting management -- users create, edit, and delete meetings with details like title, time, recurrence, and location
Invitation workflow -- users invite participants (internal or external) and send invitations via email or push notifications
Free/busy overlays -- users view their calendar and see free/busy overlays for selected participants to detect scheduling conflicts
Response handling -- users respond to invitations (accept/decline) and receive notifications and reminders across devices

Non-Functional

Scalability -- support millions of users with hundreds of millions of events; handle burst traffic during business hours
Reliability -- never lose an event creation or RSVP update; notifications must be delivered at least once
Latency -- calendar views load in under 300ms; real-time RSVP updates propagate within 2 seconds
Consistency -- strong consistency for event creation and RSVPs to prevent double-bookings; eventual consistency acceptable for notification delivery

Interview Reports from Hello Interview

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

Also commonly asked at: Amazon, Microsoft.

What Interviewers Focus On

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

1. Event Data Model and Time Handling

Calendar events have complex temporal properties including time zones, recurring patterns, and exceptions. Interviewers want to see a thoughtful data model.

Hints to consider:

Store event times in UTC with the creator's timezone for display; convert to each viewer's timezone at read time
Model recurring events with an RRULE pattern (RFC 5545) and store exceptions (cancellations, modifications) separately
Avoid materializing all occurrences of a recurring event; compute them on-the-fly within the queried time range
Handle DST transitions by using IANA timezone identifiers rather than fixed UTC offsets

2. Invitation Fan-Out and Notification Pipeline

Creating a meeting with many participants triggers a fan-out workflow. Interviewers expect this to be asynchronous.

Hints to consider:

Decouple event creation from invitation delivery using an outbox pattern or event-driven architecture
Publish an event_created message to Kafka; notification workers consume and send invites via email/push
Schedule reminders as delayed messages using Redis sorted sets or a job scheduler
Ensure idempotent invitation processing to handle retries without sending duplicate emails

3. Free/Busy Query Optimization

Checking availability across multiple participants requires efficient time-range queries. This is often the performance bottleneck.

Hints to consider:

Index events by (user_id, start_time) for efficient range scans within calendar view windows
Cache per-user busy intervals for the current week in Redis for fast overlap detection
For group availability, query each participant's busy times in parallel and compute intersection
Precompute free/busy bitmaps (one bit per 15-minute slot) for fast availability merging

4. Concurrency and Double-Booking Prevention

Concurrent event creation for shared resources (meeting rooms) or RSVP processing can cause conflicts.

Hints to consider:

Use optimistic concurrency control with version numbers on events; reject updates with stale versions
For shared resources, use conditional writes or distributed locks to prevent double-booking
Make RSVP updates idempotent using (event_id, user_id, response) as a unique constraint
Handle edit conflicts by showing the user a conflict resolution UI rather than silently overwriting