Section 3: Twelve Reads, One Write, and a Burst at Ten to the Hour - Scale Estimation & Workload Analysis

Executive Summary: This section derives every number the rest of the design will spend, starting from 200M daily users: mutations, fan-out, tickles, views, sync, free/busy, storage, the change log, the reminder horizon and bandwidth. Two results matter most. A trillion instance rows is why recurring events are stored as rules. Sixteen million reminders due in one minute is why the clock gets its own service. The section ends by mapping each forcing number to its consequence, rejected alternative and flip trigger.

The interviewer taps Section 2's promises: "Google scale. How big is that?" You state the anchors aloud so they can be corrected: ~1B registered accounts, 500M MAU, 200M DAU, and 2.5 devices per active user. Each user has a primary calendar plus about one shared or team calendar, which gives ~1B active calendars. On top of that are ~10M rooms across enterprise tenants. Each active user carries ~20 active recurring series, so 500M × 20 = 10B active series. An event has 3 participants on average.

Throughout, peak = 3× average: Monday morning, when Americas and European business hours overlap.

Writes and the Fan-Out They Trigger

MUTATIONS (create / update / delete / RSVP)
  200M DAU × 5 mutations/day          = 1B mutations/day
  1,000,000,000 ÷ 86,400 s            ≈ 11.6K/s average
  11.6K × 3                           ≈ 35K/s peak
  Mix: 30% creates = 300M/day (25% recurring = 75M new series/day)
       40% updates, 20% RSVPs = 200M/day, 10% deletes

FAN-OUT (attendee copies + change-log rows)
  1B × 3 calendars                    = 3B calendar writes/day
  3B ÷ 86,400                         ≈ 35K/s average → ×3 ≈ 104K/s peak

DEVICE TICKLES (before coalescing)
  3 calendars × 2.5 devices           = 7.5 pushes per mutation
  1B × 7.5                            = 7.5B/day ≈ 87K/s average → ≈ 260K/s peak

Key Insight: One user action becomes three calendar writes and seven and a half pushes. Only the organizer's write must be synchronous. Everything downstream is a multiplier that grows with guest count, and a multiplier has no place inside a 300 ms acknowledgement.

Quick check before moving on: