Problem Statement: A Live Attendance System, Not a Form
Frames the product as a capacity-critical real-time system with hot events, not a CRUD RSVP form.
Problem statement
Design an event RSVP and live updates platform. Organizers create an event with an invitation link, a capacity, and optional check-in requirements. Guests respond Yes, No, or Maybe. The system must show live counts to both organizers and attendees, promote waitlisted guests when capacity frees up, scan QR codes at the door for physical events, bound concurrency for virtual events, notify people when anything changes, and integrate with calendar systems.
The trap in this question is treating it as a small CRUD app. It is not. The defining property is that demand is correlated in time and space: thousands of people touch the same event object in the same seconds. A popular event invitation lands in a group chat, and five hundred people open one event page at once. An arena doors-open time concentrates twenty thousand QR scans into thirty minutes. A virtual keynote admits a bounded number of concurrent participants. Ticketmaster publicly reported roughly 3.5 billion system requests in one day during the Taylor Swift Eras Tour onsale; that figure is company-reported context, but it proves the request-shape this design must survive: enormous read thundering herd plus a write storm on one hot key.
Why the problem is distinctive
Three properties separate this from ordinary web backends. First, capacity is an invariant, not a metric: overselling a 200-seat venue or admitting a 201st concurrent participant is a correctness failure, so the capacity ledger needs atomic, single-writer semantics even while everything around it is eventually consistent. Second, live counts are fan-out work: the write rate is modest, but the number of people who must see each change can be huge, so the hard subsystem is coalescing and distribution, not storage. Third, the door is adversarial and offline: QR scanners lose connectivity exactly when crowds are densest, so check-in must work degraded and reconcile later.
The four architectural planes
- Write plane: event metadata, RSVP responses, capacity ledger, waitlist, check-in records. This plane is small in QPS and strict in correctness.
- Fan-out plane: live count and status projections pushed over WebSocket or SSE to every viewer of every event. This plane dominates message volume.
- Notification plane: push, email, SMS, and calendar updates triggered by state changes and time-based rules.
- Operations plane: organizer dashboards, scanner fleets, fraud and abuse controls, analytics.
A strong answer keeps the planes separate. The fan-out plane may lag or degrade without making the write plane wrong. A scanner outage must not corrupt the check-in ledger. A notification backlog must never block an RSVP write.
Key Highlights
- •Capacity is an invariant: the ledger must never oversell, even under a hot-event write storm.
- •Live counts are a fan-out problem: coalesce updates before distributing to hundreds of thousands of viewers.
- •Ticketmaster publicly reported about 3.5 billion requests in one day during a mega onsale: hot-key thundering herd is the reference workload.
- •Four planes: writes, fan-out, notifications, operations. Degrade them independently.
- •Door-time check-in must survive connectivity loss and reconcile afterward.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will separate correctness-critical writes from eventually consistent live projections before choosing any technology."
- "Let me define what must never be wrong, which is capacity, versus what may be briefly stale, which is the visible count."