Katkat

Design a Calendar System

LinkedInSoftware Engineer · Technical Screen

Last 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

  1. Event Management: Users can create, update, and delete single and recurring events (e.g., daily, weekly, custom iCalendar RRULE patterns).
  2. Calendar View: Users can view all events on their calendar within a specified time range (e.g., day, week, month view).
  3. Invitations & RSVP: Organizers can invite other users. Invitees can view invitations and respond with Accepted, Declined, or Tentative.
  4. Reminders: Users receive push or email notifications configured for X minutes prior to an event.

Non-Functional Requirements

  1. Scale: 100 million daily active users (DAU).
  2. Performance: Querying a 1-month calendar view should return in under 100 ms.
  3. Availability & Consistency: High availability for reads; strong consistency for attendee invitation state and event modifications to avoid phantom meetings.
  4. 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?