Section 8: One Edit, Fifty Thousand Calendars - Deep Dive: Invitations, Fan-Out & Sync

Executive Summary: Section 7 made Platform Sync correct on Priya's calendar; this section makes it correct everywhere else. We trace one edit from the outbox to fan-out workers, make out-of-order delivery harmless with per-event versions, and run RSVPs in reverse. Then come iMIP guests, the 50,000-member all-hands that flips to merge-on-read, sync tokens, coalesced tickles, and spam. The lesson to keep: copy data only when the copy count is bounded, and push signals, never payloads.

The interviewer taps the arrow from "Calendar Store" to "Fan-out Service." "That arrow is doing a lot of work. Priya moves Platform Sync. Walk me through how Tomás's phone finds out."

The Spine: Outbox, Stream, Fan-Out

You: "Priya's edit commits in one transaction on her partition: the canonical event row, a change-log row on her calendar, and an outbox row. That's the 300 ms acknowledgement. I never write to the queue from the API server: a dual write either loses fan-outs or fans out edits that rolled back. A relay tails the outbox into a change stream partitioned by the organizer's calendar_id, so every edit to ev_7f3k lands in one partition, in commit order."

Fan-out workers consume that stream. For each guest they write two rows on the guest's calendar partition: the denormalized ~1 KB attendee copy and a change-log entry. That's Section 3's ~104K/s of peak calendar writes, asynchronous on purpose: a synchronous fan-out can't fit a 1,000-guest edit into 300 ms, and pointer-and-join would turn each of the ~70K/s peak week views into a scatter across organizers' partitions.