Design Google Calendar

Assume 900 million accounts, 300 million of them opening a calendar view on a given day, and about 0.8 new events or edits per active user a day. Reminders are the surprise: many people get several a day, and they bunch up at hour and half-hour boundaries.

All authoritative data lives in an event store partitioned by calendar id: series rows with their rules, single events, per-occurrence exceptions, attendee rows and ACLs. The view service reads the rows overlapping the requested window and expands repeating rules into occurrences in memory. Every write appends to a per-calendar change log, which feeds three derived systems: fan-out to attendees' calendars, a cache of busy intervals for availability queries, and the reminder scheduler.

Keeping the derived systems behind the change log matters. A slow reminder pipeline or a rebuild of the busy cache never blocks someone saving an event, and every derived view can be recomputed from the store if it goes wrong.

A series is a single row: start as a local wall-clock time plus an IANA zone (for example 09:30 in Asia/Kolkata), duration, the rule string, and an optional end. Changes to single occurrences are separate exception rows keyed by (series_id, original_start). An exception either cancels that occurrence or overrides fields such as time, title or location. The original start is the identity of the occurrence and never changes, so even an occurrence moved twice can still be matched to its slot in the rule.

To render a window, load series that could overlap it, generate occurrences from the rule between the window bounds, drop or replace any that have exceptions, and add exceptions that were moved into the window from outside. Rule expansion is cheap, a few microseconds per occurrence, and a week view rarely produces more than a few hundred. The expensive part is loading rows, which is why the index needs the open-ended flag: without it, a series that started in 2019 and never ends would be missed by a naive "start within window" query.

A weekly 10:00 meeting in New York is at 14:00 UTC in summer and 15:00 UTC in winter. If you stored the series as a UTC instant, it would drift by an hour twice a year. If you stored a fixed offset like -04:00, the same thing happens. Only the zone name plus the tz database can produce the right instant for each occurrence, so expand in the series' own zone first, then convert to the viewer's zone. Edge cases need written policies: a 02:30 occurrence on the night clocks jump from 02:00 to 03:00 does not exist, and RFC 5545 says to shift it forward by the length of the gap; a 01:30 occurrence on the night clocks fall back happens twice, and you pick the first.

Governments change zone rules with a few weeks' notice. When a new tz database release arrives, roll it out to every server, then recompute derived data (busy cache, scheduled reminders) for calendars in the affected zones. Because series store local time and zone, the source data needs no change at all.

Editing the rest of a series is a split. The original series gets an UNTIL just before the chosen occurrence, and a new series starts there with the new details, linked to the old one so clients can show them as related. Exceptions after the split point move to the new series or are dropped if they no longer match. Doing this in one transaction on the calendar's shard keeps the two halves from overlapping or leaving a gap.

A meeting with six guests lives on the organiser's calendar, but each guest's week view must show it quickly. Reading the organiser's shard for every guest's view would turn each page load into many cross-shard lookups. Instead, write an attendee copy into each guest's calendar: the time fields, rule and exceptions copied from the organiser, plus the guest's own response, reminders and colour. The fan-out worker applies organiser edits to every copy from the change log, so guests see changes within seconds. For a 4,000-person all-hands, fan-out runs in batches, and guests in the same organisation share one cached canonical record to cut the work.

The scheduling assistant asks for busy intervals for many people across a working day or a week. Expanding every person's series on every query would work but wastes CPU, because the answer rarely changes. The busy-interval builder listens to the change log and keeps, per calendar, a sorted and merged list of busy intervals for the next twelve weeks, stored as compact pairs of minutes. A query reads one small list per person and intersects them, which takes microseconds. Beyond twelve weeks, the service expands on demand. Privacy is enforced here as well: availability returns only intervals unless the caller is allowed to see details.

Most meetings start on the hour or half hour, and most reminders are set for 5, 10 or 30 minutes before. So reminder load piles up just before each boundary. The scheduler expands the next 48 hours of reminders into per-minute buckets keyed by fire time, rebuilds affected entries from the change log when events move, and dispatches each bucket 30 seconds early to the push system with a deliver-at time. Devices hold the notification until that moment. The heavy lifting happens in a smooth stream ahead of time, and the exact-minute spike is absorbed by phones, not by our servers.