Design Google Calendar — System Design Interview Practice

Interview prompt

Design a collaborative calendar service for event CRUD, recurring meetings, invitations, free/busy lookup, reminders, and shared calendars with correct timezone and concurrency semantics.

• Define event versions, attendee ownership, invitation state, recurrence rules, timezone/DST behavior, calendars, and sharing permissions.
• Support optimistic concurrency and deterministic conflict handling; make recurring instances, exceptions, reminders, and notifications idempotent.
• Optimize time-range and free/busy reads while keeping writes durable, indexed asynchronously, and safe during fan-out to attendees.
• Explain privacy, calendar deletion, offline sync, duplicate notifications, recovery, observability, and degraded reads.

Requirements and scale assumptions

• Create, update, move, cancel, and delete events; expand recurrence rules; add exceptions, attendees, conferencing links, and reminders.
• Provide day/week range queries, free/busy lookup, shared calendars, invitations/RSVPs, search, and incremental sync tokens.
• Handle concurrent edits with versions, enforce ACLs, suppress duplicate notifications, support timezone changes, and recover missed jobs.
• Return calendar range reads with p95 under 200ms and resolve concurrent edits without lost updates.
• Scale to tens of millions of users and large attendee fan-out without a single hot key or unbounded synchronous work.
• Do not lose committed state; make retries and duplicate events safe.
• Degrade safely when downstream workers, caches, or external dependencies fail.
• 50M users, 500M events, and meetings with up to 100k attendees
• Partition by the primary tenant, user, item, or geographic key and isolate hot partitions.
• Keep serving state bounded; retain raw events or durable records for replay and auditing.

• Peak scale: 50M users; 500M events — Capacity assumption that drives partitioning and backpressure.
• Latency target: range p95 < 200ms; no lost updates — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — Versioned event and ACL records are authoritative; indexes, reminders, and notification jobs are derived.
• Async boundary: At-least-once workers — Keep Event storage with time-based indexing, Conflict resolution for concurrent edits, Cron jobs for recurring events off the synchronous path.

Key entities

• CalendarEventeventId, calendarId, organizerId, startAt, endAt, timezone, version

  Versioned event with recurrence, attendee, and timezone semantics for google calendar.

• RecurrenceRuleeventId, rrule, timezone, exceptions, effectiveAt

  Expansion rule and exceptions used to derive recurring google calendar instances.

• AttendeeResponseeventId, attendeeId, response, sequence, updatedAt

  Idempotent attendee invitation and RSVP state.

• SyncCursorprincipalId, calendarId, token, version, expiresAt

  Incremental sync position for reconnecting clients.

Data flow

1. 1. Validate timezone and calendar policyThe API checks google calendar ACLs, recurrence limits, attendee permissions, timezone rules, and idempotency before writing.
2. 2. Commit an event versionThe calendar service conditionally writes the event, recurrence exceptions, attendee sequence, and tombstones.
3. 3. Expand ranges and remindersWorkers materialize bounded google calendar instances, free/busy intervals, and reminder jobs from committed versions.
4. 4. Fan out invitations and sync deltasInvitation, RSVP, and incremental sync consumers process the event with deduplication and cursor ordering.
5. 5. Recover missed jobs and conflictsRepair workers replay events, report stale projections, and preserve conflict evidence rather than overwriting edits.

Deep dives and trade-offs

• Timezone, recurrence, and exceptionsStore UTC instants plus the original timezone and recurrence rule; expand with a pinned timezone database version. Model exception and cancellation instances explicitly so a single edit does not rewrite the series ambiguously. Bound expansion windows and schedule future reminders from durable recurrence state.
• Concurrent edits and invitationsUse event version and attendee sequence checks to reject or merge stale edits deterministically. Separate organizer truth from attendee response state and make notification jobs idempotent. Return conflicts and current version so offline clients can reconcile instead of silently losing changes.
• Sync and reminder reliabilityIssue versioned sync cursors with snapshot fallback when a client is too far behind. Track reminder schedule, delivery attempts, and provider receipt independently from event commit. Measure range freshness, conflict rate, missed reminders, and duplicate notifications.
• Materialized recurrence versus query-time expansionMaterialize bounded near-term instances and expand long-range views asynchronously from the rule. Expanding every recurring series on every read creates unpredictable latency and duplicate reminder risk.
• Strong range reads versus projection freshnessServe indexed ranges with a visible version and fall back to authoritative state for narrow critical reads. Hiding stale free/busy data can cause double booking or missed meeting conflicts.
• Push sync versus cursor pullUse push as a wake-up signal and cursor pull as the correctness path for offline and reconnect recovery. Push-only sync loses changes when a device sleeps or changes networks.