Google Calendar

Assume 500M monthly active users, 100M daily active users, an average of 8 visible calendars per daily user including owned, shared, holidays, and subscriptions, and 300 retained event records per active user after compacting old data into colder storage.

Assume 25M event creates, updates, deletes, and exception writes per day, 50M RSVP updates per day, 1B day or week view reads per day, 120M free/busy queries per day, 600M reminder triggers per day, and a peak multiplier of 10x over average. A stored event or override averages about 1 KB before indexes, while attendee rows average about 200 bytes.

• Event writes: 25M event mutations per day divided by 86,400 seconds is about 289 writes per second, rounded to 290. With a 10x peak multiplier, plan for about 2,900 writes per second.
• RSVP writes: 50M RSVP updates per day divided by 86,400 seconds is about 579 writes per second, rounded to 580. Peak is about 5,800 writes per second.
• Calendar views: 1B day or week view reads per day divided by 86,400 seconds is about 11,574 reads per second, rounded to 11,600. Morning traffic and Monday planning can drive 10x peaks, so size the read path for about 116,000 reads per second.
• Free/busy: 120M queries per day divided by 86,400 seconds is about 1,389 queries per second, rounded to 1,400. A large meeting query with 50 attendees fans out internally, so the service must batch and cache busy windows.
• Reminders: 600M reminder triggers per day divided by 86,400 seconds is about 6,944 timer firings per second. With 1.4 delivery channels per trigger, channel sends are about 840M per day, or about 9,700 sends per second on average.
• Event storage: 500M active users times 300 retained event or override records is 150B records. At about 1 KB each, raw event storage is about 150 TB.
• Attendees: if each event averages 2 attendee rows, 150B events produce about 300B attendee rows. At about 200 bytes each, raw attendee storage is about 60 TB.
• Total storage: after secondary indexes by calendar and time, attendee indexes, change logs, reminder tasks, three-way replication, backups, and compaction overhead, a production system should plan for roughly 700 TB to 1 PB.

• events.calendar_id, start_utc, end_utc supports bounded day and week reads for non-recurring events and materialized overrides.
• events.parent_series_id, original_start_utc finds overrides and cancellations for a recurring series within a requested window.
• event_attendees.attendee_user_id, updated_at supports invitation inboxes and attendee-specific sync.
• calendar_acl.principal_id, calendar_id supports listing calendars visible to a user and enforcing access quickly.
• reminder_tasks.trigger_at_utc, status lets timer workers claim due reminders in order.
• calendar_change_log.calendar_id, sequence_id supports incremental sync tokens and replay.

A calendar has many ACL entries and many organizer event records. A recurring series master has zero or more override event rows. Attendee rows reference the event version they apply to, and response_status can differ by attendee. Reminder tasks reference event records but are derived data and can be rebuilt after a scheduler failure. Change-log rows are append-only records emitted in the same transaction as the mutation they describe.

At large scale, use a distributed wide-column or document store partitioned by calendar_id and time bucket for event reads, plus a separate event_id lookup table for direct edits. Bigtable, Spanner, DynamoDB, Cosmos DB, or Cassandra can work if the design preserves conditional writes, time-range scans, and durable change-log ordering.

For recurrence, avoid blindly materializing all future occurrences into the primary store. Store the RRULE and exceptions as source of truth, optionally materialize a rolling horizon such as the next 90 or 180 days for hot calendars, and regenerate that horizon when the series or timezone rules change.

A strong design starts with the event model. A calendar is a container with ACLs. An event row can be a one-off event, a recurring series master, or an override for one instance. The organizer copy owns title, location, conferencing data, start and end, recurrence, visibility, and sequence. Attendee rows own per-attendee response state and optional comments.

Store both UTC instants and the originating timezone context. UTC is used for ordering, reminders, and range scans. The local wall-clock fields and IANA timezone are used to preserve user intent and regenerate future occurrences when daylight-saving rules change. For all-day events, store dates separately from timestamps so they do not shift when viewed from another timezone.

Do not model each invited attendee as a fully independent event unless the product needs attendee-local edits. That approach makes organizer updates, cancellations, and conflict detection harder. Instead, use organizer event plus attendee state, and optionally create attendee-visible projections derived from the authoritative event and RSVP rows.

RRULE from RFC 5545 can express daily, weekly, monthly, yearly, count-limited, until-limited, and rule-by-field recurrences. Materializing every future occurrence is dangerous because an unbounded daily rule could create thousands of rows per user and timezone rule changes would require huge rewrites.

The preferred model stores the series master with recurrence_rule, recurrence_until_utc, local start and end, and timezone. For a view request, expand only the requested window, such as one week or one month, then overlay exceptions. An exception is keyed by parent_series_id plus original_start_utc. A cancelled exception suppresses one generated occurrence; an edited exception replaces the generated occurrence with its own start, end, title, reminders, or attendee changes.

Selective materialization is still useful. For hot calendars, materialize a rolling horizon such as the next 90 days into a cache or derived table to accelerate day views and free/busy queries. The materialized horizon is derived data and must be invalidated when the RRULE, timezone, or exceptions change.

Invitations require separating organizer-controlled event fields from attendee-controlled response fields. The organizer can change time, title, recurrence, conferencing data, and attendee list. Each attendee can set response_status to accepted, tentative, declined, or needs_action. Resource attendees such as rooms may auto-accept or decline based on availability and policy.

Organizer edits increment the event sequence and generate sync changes for every visible attendee. RSVP updates should not rewrite the organizer event body; they update event_attendees and notify the organizer if the product needs that signal. If an attendee is removed from a meeting, future sync responses should include a tombstone so their devices delete the invitation.

Sharing permissions exist at calendar level and sometimes event level. Owner and writer roles can mutate events, reader can view details, and free_busy_reader can only see busy blocks. Enterprise policies may restrict external sharing or hide guest lists. Every day view, event detail, free/busy response, and sync delta must apply the same visibility rules.

Free/busy is a derived availability view. It should include confirmed and tentative events that block time, exclude declined events, exclude events marked transparent, and hide titles or descriptions from callers who only have availability access.

A simple query fetches each calendar's events over the requested time range, expands recurring series within the range, overlays exceptions, and merges intervals. For a meeting with many attendees, fan-out can be expensive. Batch calendars by shard, cap the time range, cache common windows for rooms and active users, and return partial errors per calendar rather than failing the whole query.

Conflict detection is advisory for humans but often strict for rooms and resources. For human attendees, the create API can warn about conflicts while allowing the organizer to proceed. For conference rooms, use a conditional booking record or resource calendar write so two organizers cannot reserve the same room at the same time.

Reminders are scheduled tasks derived from event start times and user preferences. On event create or update, compute trigger_at_utc for each reminder by subtracting the lead time from the occurrence start. For recurring events, either lazily generate reminder tasks for a rolling horizon or materialize the next due occurrence per reminder and advance it after delivery.

The timer service should store tasks ordered by trigger_at_utc, claim due tasks with leases, and send to a notification service with an idempotency key. It must handle common spikes at 5 minutes before the hour, retry provider failures, and cancel or update pending reminders when an event changes or an attendee declines.

Reminder delivery is at-least-once internally and effectively-once at the user experience layer. Duplicate sends are prevented with dedupe keys such as user, event or instance id, channel, and trigger time. If the timer service is delayed, it should deliver late reminders only within a bounded grace window to avoid waking users for stale meetings.

Timezone bugs are common in calendar interviews. Store start_utc and end_utc for efficient ordering, but also store local_start, local_end, and the IANA time_zone that expressed the user's intent. A weekly 9 AM meeting should be expanded as 9 AM in that timezone for each occurrence, then converted to UTC using the timezone database version in effect.

DST creates nonexistent local times, repeated local times, and changing offsets. The API should reject impossible times or apply an explicit product rule, such as choosing the later valid instant. All-day events should be stored as local dates and rendered in the calendar timezone, not converted through midnight UTC.

Incremental sync should use sequence-based tokens, not updated_at polling. Every mutation appends to calendar_change_log with a monotonic sequence. Devices ask for changes after their last sequence and receive updates plus tombstones. If a device is offline longer than the retained log window, return 410 Gone and force a full resync so it cannot silently miss deletes or ACL changes.

Alternative one is full occurrence materialization. It makes reads simple, but recurring events with no end date can explode storage and require expensive rewrites after timezone or RRULE changes.

Alternative two is purely lazy expansion with no caches. It is storage efficient and correct, but popular calendars and large free/busy queries may suffer high p99 latency.

Alternative three is a consensus-backed global relational database for all calendar writes. It simplifies consistency and cross-region failover, but increases write latency and cost compared with home-region writes plus replicated reads.

Do not use this full calendar architecture for a simple reminder app or personal to-do list with no sharing, no recurrence complexity, no multi-device sync, and no attendee workflow. A local-first task store with simple alarms is much cheaper when collaboration and free/busy semantics are not required.