RSVP Service Low-Level Design: Capacity Management, Waitlist, and Reminder Pipeline

What Is an RSVP Service?

An RSVP service manages attendance for events with limited or unlimited capacity. It handles registration, waitlist promotion, cancellations, and reminder delivery. Systems like Eventbrite and Meetup expose similar capabilities. The core challenge is enforcing capacity limits under concurrent registrations without overselling while keeping the waitlist fair.

Requirements

Functional Requirements

Register a user for an event; enforce seat capacity
Place users on a waitlist when capacity is full
Automatically promote waitlisted users when a seat opens
Allow cancellations with configurable cutoff windows
Manage guest list per event (export attendee details)
Send automated reminders at configurable intervals before the event

Non-Functional Requirements

No overselling: exactly capacity registrations must be confirmed at any time
Fair FIFO waitlist ordering
Scalable to thousands of concurrent registrations during flash sales
Reminder pipeline reliability with at-least-once delivery

Data Model

events: event_id, title, capacity, waitlist_limit, registration_cutoff, cancellation_cutoff, reminder_schedule (JSON array of offsets in seconds)
registrations: registration_id, event_id, user_id, status (confirmed, waitlisted, cancelled), waitlist_position, registered_at, updated_at
seats: event_id, confirmed_count — maintained atomically; alternatively derived from registrations count
reminders: reminder_id, event_id, user_id, send_at, channel (email, push, sms), sent_at, status

A composite unique index on (event_id, user_id) in registrations prevents duplicate registrations. The waitlist_position column is used only for waitlisted rows and is assigned via a sequence or counter per event.

Core Algorithms

Capacity Enforcement

Use an optimistic locking or database-level counter to prevent overselling. On registration attempt: begin transaction, select confirmed_count from seats with FOR UPDATE, check if confirmed_count < capacity, insert registration with status=confirmed and increment confirmed_count, commit. If count equals capacity, insert with status=waitlisted and assign next waitlist_position. This serializes seat allocation at the row level without full table locks.

For high-concurrency flash registrations, use Redis with INCR on a key like event:{id}:confirmed capped at capacity. If INCR returns a value above capacity, immediately DECR and return waitlist. Write the final status to the database asynchronously.

Waitlist Promotion

When a confirmed registration is cancelled: decrement confirmed_count, find the earliest waitlisted registration (ORDER BY waitlist_position ASC LIMIT 1), update its status to confirmed, increment confirmed_count, and send a promotion notification. Wrap in a transaction. If the promoted user does not confirm within a configurable window (e.g., 24 hours), cancel their slot and promote the next person.

Reminder Pipeline

At registration time, schedule reminder records in the reminders table for each offset in reminder_schedule. A cron job or scheduled worker queries WHERE send_at <= NOW() AND sent_at IS NULL, batches rows, publishes to a message queue (SQS/Kafka), and marks sent_at. Consumer workers deliver via email/push/SMS. Idempotency key is reminder_id; duplicate deliveries are deduplicated at the consumer.

API Design

POST /events/{id}/registrations — register user; returns confirmed or waitlisted status
DELETE /events/{id}/registrations/{user_id} — cancel registration
GET /events/{id}/registrations — paginated guest list (admin only)
GET /events/{id}/registrations/{user_id} — check individual status
GET /events/{id}/waitlist — ordered waitlist (admin)
POST /events/{id}/reminders/test — trigger test reminder (admin)

Scalability Considerations

For high-demand events, move seat allocation fully into Redis using a Lua script that atomically checks and increments the counter, eliminating database round trips on the hot path. Persist the Redis state to the database via a background reconciliation job every few seconds.

Partition the reminders table by send_at date to keep the scheduler query on a small partition. Use a distributed lock (Redlock) when the scheduler runs across multiple instances to avoid duplicate scheduling. Fan out reminder delivery via multiple consumer workers scaling horizontally with the queue depth.

For guest list exports, use a background job that writes to S3 and returns a signed URL rather than streaming rows directly from the database.

Summary

An RSVP service enforces seat capacity through transactional counters or Redis-based atomic operations, manages a FIFO waitlist with automatic promotion on cancellation, and drives reminders through a scheduled pipeline backed by a message queue. The key design decisions are the atomicity mechanism for seat allocation and the reliability guarantees of the reminder delivery path.

{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “How do you enforce event capacity with atomic decrements?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Use an atomic counter in Redis (DECR) or a database row with optimistic locking (UPDATE events SET capacity = capacity – 1 WHERE id = ? AND capacity > 0). If the decrement returns 0 or fails the WHERE condition, reject the RSVP and optionally offer waitlist enrollment. Redis is preferred for high-throughput ticketing to avoid DB contention.”
}
},
{
“@type”: “Question”,
“name”: “How does waitlist promotion work on cancellation?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “When a confirmed attendee cancels, increment the capacity counter and dequeue the head of the waitlist. Send the waitlisted user a time-bounded reservation hold (e.g., 15-minute TTL) via a notification. If they confirm within the window, decrement capacity and confirm; otherwise, promote the next waitlist entry. Use a persistent queue (SQS, Redis list) to guarantee at-least-once promotion.”
}
},
{
“@type”: “Question”,
“name”: “How do you model guest list management?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Each RSVP row includes a guest_count field capped by per-attendee guest limits defined on the event. Capacity enforcement subtracts (1 + guest_count) from available slots atomically. Guests are stored as child rows referencing the RSVP, optionally with names for check-in. Expose a guest list export endpoint restricted to the event organizer.”
}
},
{
“@type”: “Question”,
“name”: “How is the reminder pipeline designed?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Schedule reminders as delayed jobs (e.g., Sidekiq, Celery, SQS delayed messages) at RSVP confirmation time, targeting event_time – 24h and event_time – 1h. Store scheduled job IDs on the RSVP row so they can be cancelled on withdrawal. Fan out notifications via a channel router (email, SMS, push) using a templating service. Idempotency keys prevent duplicate sends on retry.”
}
}
]
}