System Design

Calendar Scheduling

Design a calendar and meeting scheduling service like Google Calendar or Outlook.

Functional requirements

• Users create, edit, and delete events (title, start and end time, time zone, optional attendees) and view any day, week, or month of their own or a colleague's calendar in their time zone.
• Events can repeat on a rule (e.g., every Tuesday at 10am Pacific until June 30), and one occurrence of a series can be moved or canceled without affecting the rest.
• Attendees receive an invitation, respond accept, decline, or tentative, and see the organizer's later edits; the organizer sees every response.
• Given attendees and a duration, the system suggests open slots in working hours where everyone is free, and warns the organizer of conflicts if they pick a busy time anyway.
• Users receive a reminder notification a configurable number of minutes before each event starts.

Non-functional requirements

• Calendar views are the critical path: p99 under 300ms for a week view including expanded recurring events; free/busy search across 20 attendees has p99 under 1s.
• Availability over freshness: a colleague's calendar may be up to 30 seconds stale, but users see their own edits immediately, and an event's time never differs between attendees once an edit settles.
• Accepted writes are durable: a created event, RSVP, or edit is never lost; a meeting silently vanishing from a calendar is the product's worst failure.
• Correct across time zones and daylight-saving transitions: a weekly 10am Pacific meeting stays at 10am Pacific through the DST change and shows at the right local hour for every attendee.
• Reminders fire within 60 seconds of their scheduled time and never fire twice; users can only read calendars they have been granted access to.

Scaling & constraints

• 20M users, each with ~1 calendar holding ~2,000 events, of which ~20% are recurring series (~40 TB of event data at ~1 KB per event).
• 10,000 calendar views per second at peak and ~1,000 event writes per second; free/busy searches run at ~200 per second, each touching up to 20 attendees.
• Read:write ratio on the event store is roughly 20:1 (views and searches vs. creates, edits, and RSVPs).
• A series with no end date must expand at least 2 years ahead (~100 occurrences for a weekly meeting); the busiest users have ~400 recurring series and ~50 events per week.
• Reminders and event starts cluster at :00 and :30: ~500,000 reminders come due in the same minute at 9:00am Pacific on weekdays.
• Invitations and edits fan out to up to 500 attendees for company-wide events; the notification service (push and email) has p99 send latency of 2s and a ~1% transient failure rate.

Out of scope

• User accounts, authentication, and the organization directory.
• Meeting room and equipment booking.
• Video conferencing links and third-party calendar sync (CalDAV, Exchange).
• The push and email delivery infrastructure itself (assume a notification service with a send API).