Design an Event Invitations & RSVPs System

Problem statement

Design an invitations and RSVPs subsystem for a social platform. A host creates an event with date, time, timezone, location or online link, and capacity; invites a list of users or shares a public link; guests respond yes, no, or maybe; the platform tracks tallies, manages waitlists for capacity-limited events, sends reminders as the event approaches, and propagates changes when the host edits or cancels the event. Calendar integration lets guests add the event to Google, Apple, or Outlook calendars and receive updates there.

The feature looks like simple CRUD until you examine the write shape. One host action—publishing an event—fans out to tens, thousands, or occasionally millions of invitation rows and notifications. One guest action—responding yes—must atomically touch a seat ledger when capacity exists, update a tally that every other guest reads, and trigger downstream projections. One host edit—moving the event by an hour—must re-notify every responder and push an update into external calendars across timezones. And the reminder subsystem must fire tens of millions of durable timers that cluster at the same wall-clock minutes because events start on the hour.

Why the problem is distinctive

Three subsystems collide here. First, fan-out: invitation delivery and guest-list materialization follow the same mathematics as social feeds, with a heavy tail of viral or public events. Second, consistency: RSVP tallies and seat accounting need different consistency models—approximate-fast for display counts of huge public events, exact-serializable for the last three seats of a 50-person dinner. Third, time: reminders and calendar sync make the system a durable timer service where timezone, DST, and correlated burst behavior dominate the design. A strong interview answer separates these three planes immediately.

The four architectural planes

1. Identity and graph plane: who may be invited, who may see the guest list, host and co-host authority, external email invitees.
2. Invitation plane: durable invitation rows, RSVP state machine, waitlist, tallies, guest-list projections.
3. Notification plane: multi-channel delivery of invites, updates, and reminders with per-user routing and degradation.
4. Time plane: durable reminder scheduling, timezone-correct instants, calendar artifact generation (ICS), and two-way sync with external calendar providers.

The attached brief requires event creation with date and time, invitation by list or share link, yes-no-maybe tracking, and reminders as the event approaches, plus scalability for large invitations, notifications for updates, calendar integration, and consistent RSVP tallies. Every scale number below is either a cited public figure or an explicitly labeled design assumption.