## Design a Calendar System Design the backend for a calendar service similar to Google Calendar or Outlook Calendar. Users can create, view, edit, and delete events on their own calendars; invite other users to events and see their responses (accept / decline / tentative); create **recurring** events (e.g. "every weekday at 9am"); receive **reminders/notifications** before events start; and check **free/busy** availability across one or more people when scheduling a meeting. Focus on the data model, the read and write paths for events (including recurrence), the invitation flow, the reminder/notification pipeline, and how the system scales and stays consistent. ```hint Where to start Separate **functional** requirements (event CRUD, invitations + RSVPs, recurring events, reminders, free/busy lookup, sharing) from **non-functional** ones (high read availability, low-latency day/week/month rendering, durability of events, eventual consistency of notifications) before you pick storage. Drive the design from the dominant access pattern: "give me all of user U's events overlapping time window [start, end]". ``` ```hint Recurrence Do **not** materialize every instance of a recurring (possibly never-ending) event. Store the recurrence as a rule (an RFC 5545 `RRULE`, e.g. `FREQ=WEEKLY;BYDAY=MO,WE,FR`) plus a start time and timezone, and **expand it on read** within the requested bounded window. Keep per-instance edits and deletions ("this event only") as separate **exception/override** rows keyed by the original occurrence's start time. ``` ```hint Reminders at scale Avoid scanning all events every minute. Push due reminders into a **time-bucketed scheduler** — a delay queue or a "due_at" index sharded by minute — so a worker only pulls the small set of reminders firing in the current bucket, then fans them out to push/email/SMS. ``` ### Constraints & Assumptions The post states only "design a calendar system," so the following are reasonable working assumptions to scope the problem (state your own and adjust during the interview): - Roughly 100M users; read-heavy — viewing/rendering calendars vastly outnumbers writes (assume ~100:1 reads to writes). - A typical user has on the order of thousands of events; power users (shared team/resource calendars) may have far more. - Target p99 latency for rendering a day/week/month view in the low hundreds of milliseconds. - Events are durable (must never be silently lost); reminder delivery can be at-least-once and may tolerate a small delay (seconds), but should not be hours late. - Timezones and daylight-saving transitions must be handled correctly. - Out of scope unless raised: rich text/attachments, video-conferencing integration internals, billing. ### Clarifying Questions to Ask - What is the precise scope — personal calendars only, or also shared/team calendars, meeting rooms, and other bookable resources? - How important is cross-user **free/busy** and conflict detection at scheduling time, and across how many attendees at once? - What recurrence expressiveness do we need (simple daily/weekly, or full `RRULE` with exceptions, end-after-N, until-date)? - Which reminder channels are required (push, email, SMS) and what delivery-latency SLA is acceptable? - What consistency do we need when an organizer edits an event that 50 people have already accepted — must all attendees see the change immediately, or is propagation within seconds acceptable? - Are there hard requirements around external calendar interoperability (iCal/CalDAV import/export, federation with other providers)? ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - A meeting organizer edits the time of one occurrence of a weekly recurring event that 200 people have accepted. Walk through exactly what is written and what each attendee sees, including the "this event" vs. "this and following" vs. "all events" choices. - How do you implement an efficient cross-user free/busy and conflict check when scheduling a meeting with 30 attendees, without scanning every attendee's full event history? - A user in `America/New_York` creates a recurring 9am standup; the rule must keep firing at local 9am across a daylight-saving transition. How do you store and expand the recurrence so this stays correct? - The reminder workers fall behind during a traffic spike. How do you keep reminders from being dropped or fired hours late, and how do you avoid sending duplicates when a worker retries?