Design a Calendar System
LinkedInSoftware Engineer · Technical ScreenLast updated
Tests your ability to design a scalable calendar backend that supports single and recurring events, attendee invitations, and time-based reminder notifications with timezone awareness.
Scenario
Design the backend architecture for an enterprise-scale calendar service (similar to Google Calendar or Outlook Calendar) that integrates into a professional network. Users can schedule individual or recurring meetings, invite colleagues, update RSVP statuses, and receive scheduled reminders.
Requirements
Functional Requirements
- Event Management: Users can create, update, and delete single and recurring events (e.g., daily, weekly, custom iCalendar
RRULEpatterns). - Calendar View: Users can view all events on their calendar within a specified time range (e.g., day, week, month view).
- Invitations & RSVP: Organizers can invite other users. Invitees can view invitations and respond with
Accepted,Declined, orTentative. - Reminders: Users receive push or email notifications configured for X minutes prior to an event.
Non-Functional Requirements
- Scale: 100 million daily active users (DAU).
- Performance: Querying a 1-month calendar view should return in under 100 ms.
- Availability & Consistency: High availability for reads; strong consistency for attendee invitation state and event modifications to avoid phantom meetings.
- Timezone Support: Correct representation of events across different time zones and daylight saving transitions.
Scale & Traffic Estimations
- DAU: 100 million.
- Writes: Average 1.5 event creations or modifications per active user per day (~1,800 writes/sec average, peak ~5,000 writes/sec).
- Reads: Average 8 calendar views per active user per day (~9,500 reads/sec average, peak ~25,000 reads/sec).
- Reminders: Hundreds of millions of notifications evaluated and sent daily.
What Your Design Should Cover
- API Design: Core endpoints for creating events, fetching calendar windows, and responding to invites.
- Data Model: Storage schema separating master recurring events, recurring event exceptions, and attendee status.
- Recurrence Architecture: Strategy for expanding recurring events (pre-computed/materialized vs. dynamic expansion on query).
- Notification Pipeline: Distributed reminder engine capable of triggering accurate alerts at high throughput.
- Trade-offs: Storage cost vs. query latency when indexing future events.
Hints
Hint 1
Consider decoupling the recurrence definition (using RRULE-like specifications) from one-off exceptions such as single-instance cancellations or time shifts.
Hint 2
Deciding whether to dynamically compute recurring instances at query time or to pre-materialize instances into an indexed search table dramatically impacts read latency versus write overhead.
Hint 3
For the reminder service, evaluate a time-bucketed delay queue or partitioned task scheduler rather than polling the main database on every minute boundary.
Follow-up questions
- How would you handle a user rescheduling only a single instance of a recurring event series without breaking future occurrences?
- How does your architecture support finding a common free/busy availability slot across 20 busy participants?
- If a daylight saving time (DST) transition shifts local time by one hour, how does your system ensure recurring meetings remain at the intended local hour for all participants?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.