Design Meetup

Problem statement

Design a platform where people organize in-person or virtual events by interest and location. Users discover groups, join them, create events, RSVP against finite capacity, receive reminders over push and email, sync events to external calendars, and — when the product charges — pay membership fees or buy tickets. The brief requires group creation by topic/region, event scheduling with RSVPs, notifications/reminders, and possibly ticketing, plus geo-based search and recommendations, scalability for large events, resilience to last-minute changes, and calendar integration.

The naive reading is a calendar CRUD app. The correct reading is a fan-out and coordination system. One event change by one organizer can invalidate plans for thousands of attendees, must update waitlists, must cancel or amend calendar entries, and must trigger re-notification across push, email, and in-app channels within seconds. One popular onsale can concentrate demand that is hundreds of times the platform average — Ticketmaster reports the Eras Tour onsale produced 3.5 billion system requests, four times its previous peak [[35]]. An events platform is therefore sized by its spikes, not its averages.

Public operating baseline versus design assumptions

Public figures establish category scale. Meetup's app listing reports over 60 million members [[8]], and Meetup's own recap of 2025 cites 3.5 million events and 24 million RSVPs in a single year [[1]]. Eventbrite's FY2025 annual report states creators hosted nearly 4.6 million events and issued 258 million tickets [[25]]. These are cited company figures, not requirements for our fictional system. For capacity planning this answer explicitly assumes a mature platform with 60 million registered members, 8 million monthly actives, 900 thousand daily actives, 120 thousand events created per day, 3 million RSVP transitions per day, and a 10x spike factor for headline onsales. Unless cited, every number is a stated assumption, target, or budget.

The five architectural planes

1. Discovery plane: geo search, topic search, recommendations, group discovery.
2. Community plane: groups, membership, roles, fees, moderation.
3. Event plane: scheduling, capacity, RSVP state machine, waitlists, check-in.
4. Engagement plane: notifications, reminders, calendar sync, change cascades.
5. Commerce plane: membership fees, ticketing, refunds, fraud control.

A strong interview answer keeps these planes separate: discovery is read-heavy and cacheable; the event plane is correctness-critical; the engagement plane is a durable scheduling problem; commerce is isolated for compliance.