Design a calendar with invites (Google Calendar)

Never store every instance of a recurring event: a daily meeting with no end date is infinite, and editing 'all future' would rewrite thousands of rows. Store the series once with an RFC 5545 RRULE (FREQ, INTERVAL, BYDAY, COUNT/UNTIL), a start in its time zone, and a list of EXDATEs. A change to one instance creates an exception row linked to the series with original_start identifying which occurrence it replaces; a cancelled instance is an EXDATE. 'This and following' splits the series: the old one gets UNTIL just before the chosen instance and a new series starts from it, copying attendees. Reads expand the rule only over the requested window, which is cheap with a good RRULE library, then overlay exceptions. Indexing: the calendar index holds the series with its overall range (first start to UNTIL, or open-ended), so a week query finds it even without stored instances. Edge cases that interviewers like: the 31st of the month in February (RFC rules skip it), the last Friday (BYDAY=-1FR), and RSVPs per instance, which are attendee-level exceptions.

Store recurring events in their wall-clock time plus an IANA time zone (America/New_York), not as UTC. A weekly 9:00 meeting in New York is 13:00 UTC in summer and 14:00 UTC in winter; storing UTC would shift it by an hour after the DST change. Expansion happens in the event's zone, then each instance is converted to UTC for indexing and to the viewer's zone for display. One-off events can be stored as UTC plus the original zone for display. India has no DST, which hides these bugs during local testing, but teams in India meet with US and EU colleagues daily, and a meeting with London moves for Indian attendees twice a year: that is correct behaviour and the product should show it. Time zone rules themselves change by government decision, so ship tzdata updates regularly and recompute affected future instances and reminders. All-day events are dates, not times; store them as dates with no zone, or a birthday shows on the wrong day for a traveller.

Reminders are timers: billions of them, spiky around :50 and :55 every hour. Use a time-bucketed store: rows keyed by fire minute and a shard number (to spread a hot minute across many partitions), each holding reminder IDs. Workers own shards via leases; a few seconds before each minute they read their bucket, and for each reminder check the event's current version and the attendee's RSVP before sending, so edits and cancellations need no cleanup of old reminders: stale ones are dropped at fire time. Schedule only the next occurrence of a recurring series; after firing, compute and insert the next one. This keeps the store small and makes rule edits cheap. Send through the notification service with an idempotency key (reminder_id + instance_start) so a worker retry after a crash does not send twice. Late is better than never: if workers fall behind, send reminders up to a few minutes late, and drop those for meetings that already started. Clients also schedule local notifications from synced data, which covers offline phones and acts as a backup.

Clients must show the same calendar everywhere and work offline. Each calendar has an append-only change log with a monotonic sequence number per calendar. A client sends its last sync token (encoding the sequence) and gets all events changed or deleted since then, plus a new token; if the token is too old (the log was compacted), the server returns 410 Gone and the client does a full resync of the window. Push notifications only say 'calendar X changed', which is cheap and triggers a sync, so you never push full payloads to millions of devices. Offline edits are sent later with the event's etag (If-Match); if the event changed meanwhile, the server returns 412 and the client merges field by field or asks the user. RSVPs are separate attendee resources so they rarely conflict with organiser edits. Third-party clients use CalDAV, which has the same idea (sync-collection reports with tokens), and external organisers' invites arrive as iMIP emails that the system parses into events with the external UID.

A copy per attendee (like email) makes reads local and simple, but edits must update every copy and copies drift. One authoritative event owned by the organiser plus a per-attendee index (reference + personal state like RSVP and reminders) keeps one truth and cheap reads. External attendees necessarily get copies via iMIP, which is why updates to them are sent as new emails with a sequence number.

Read-time expansion keeps storage small and edits cheap; it costs a little CPU per view. Materialising a limited horizon (e.g. next 12 months) speeds up some queries like free/busy across many people but requires re-materialising on edits. Expand at read time, and cache free/busy intervals per week.

Invites cross users in different regions, and the organiser's write must be consistent. A globally consistent database (Spanner) simplifies this at higher write latency; regional shards with async fan-out are cheaper but make cross-region invites eventually consistent. Most products accept seconds of delay for attendee copies.

Fan-out to 20k calendar indexes and 20k emails per edit is heavy, and every edit repeats it. Treat large events like groups: attendees reference a group, the index stores one entry per group membership expanded lazily, RSVPs are counted asynchronously, and edits to large events are rate limited.

Reminder volume at :55 can be 20x the average. Spread hot minutes across many shards, pre-read buckets a few seconds early, and scale notification senders ahead of known peaks (weekday mornings across time zones).

The organiser sees the change immediately (strong write), attendees a little later. Kafka retains events, so nothing is lost; workers are idempotent (upsert index rows by event_id) so replays are safe. Alert on lag; clients can fetch the event directly when opened.

Its lease expires in ~10 seconds and another worker takes the shard, processing the current and any missed buckets. Idempotency keys stop duplicates if the old worker had partially sent a bucket.

Wrong time zone rules shift meetings. Version tzdata, roll out gradually, and keep the ability to recompute instances and reminders from stored wall-clock times and zone names, which is only possible because you did not store recurring events as UTC.