What is an event RSVP manager?

A small serverless system that runs the guest list for a small event. People register through a simple form; it confirms each RSVP by email, sends timely reminders before the date, handles cancellations, runs a waitlist that auto-offers a freed spot to the next person in line, caps capacity so the event never oversells, and gives the host a live headcount. Guests can confirm, cancel, or claim an offered spot straight from the email.

How much does it cost to run?

About $2.40/month for a typical event of around 200 guests. The fixed cost is essentially zero. The variable cost is dominated by the emails the system sends — one confirmation per RSVP, a couple of reminders each, plus waitlist offers — all through SES at $0.10 per thousand. Lambda, DynamoDB, and EventBridge Scheduler add up to pennies. A 50-guest event lands near $0.80; a 1,000-guest conference lands around $9.

Which AWS services does it use?

Lambda (Python 3.14, arm64) with Function URLs for the register, confirm, and cancel links, EventBridge Scheduler for reminders and waitlist-offer timeouts, DynamoDB on-demand (with a conditional write that enforces the capacity cap), S3 (with versioning), SES inbound + outbound, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) only for the post-event thank-you note and a host Q&A helper. No API Gateway, no NAT Gateway, no always-on compute.

How does it stop the event from overselling?

Every seat is claimed by a single conditional write to DynamoDB that only succeeds if the live confirmed count is below the cap. Two people clicking 'confirm' at the same second can't both win the last seat — the database refuses the second write, and that person is offered the waitlist instead. The cap is the one number the whole system defends.

How does the waitlist work?

When someone cancels, the freed seat is offered to the first person on the waitlist — not given, offered. They get an email with a claim link that holds the seat for a set window (default 6 hours). If they claim it, they're in. If the window passes with no claim, the offer expires and the seat rolls to the next person in line automatically. Nobody is ever silently skipped, and a stale offer never blocks the seat forever.

Does it respect quiet hours?

Yes. Reminders and waitlist offers never go out between 9pm and 8am local time by default. A message that would land in the quiet window is deferred to the next morning by a one-off EventBridge Scheduler rule. The one exception is a time-critical waitlist offer where the claim window would otherwise close overnight — those can be allowed through by a host setting, because a missed seat is worse than a late-night email.

Does the host have to watch a dashboard?

No. The host gets a live headcount link that always shows confirmed, waitlisted, and open seats, plus a short daily summary email in the run-up to the event. The system runs itself; the host only steps in to change the cap, close registration early, or message the whole confirmed list. Every change is recorded in the audit table so the guest list is reconstructable after the fact.

Series · 7 parts Published June 5, 2026

Event RSVP manager

A serverless manager that runs the guest list for a small event. People register; it confirms each RSVP, sends timely reminders before the date, handles cancellations and a waitlist that auto-offers a freed spot to the next person, caps capacity so the event never oversells, and gives the host a live headcount. Guests can confirm, cancel, or claim an offered spot right from the email. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

An event RSVP manager on AWS for a few dollars a month

The whole system on one page — a register form, a guest-list keeper, and a messenger, plus the moves they share for every guest: confirm, remind, cancel, and offer.
02

How an RSVP gets confirmed

A guest fills the form and clicks confirm; a single conditional write claims a seat only if the event isn’t full. The cap is defended by the database, so two people can never win the same last seat.
03

How an RSVP reminder gets scheduled

When a guest confirms, the system books their reminders — a week out, a day out, the morning of — as one-off Scheduler rules. Quiet hours defer any reminder that would land overnight.
04

How a cancellation frees a spot

One click cancels cleanly: the seat is released, the guest’s pending reminders are deleted, and the freed seat kicks off the waitlist offer. Every step is logged so the headcount always adds up.
05

How a freed spot finds the next guest

The freed seat is offered, not given, to the first person on the waitlist. A claim link holds it for a window; if it lapses, the offer rolls to the next person automatically. Nobody is silently skipped.
06

What the event RSVP manager costs

A few dollars per event. The cost is mostly the emails it sends; the rest is pennies. Bedrock fires only on the post-event thank-you note and a small host Q&A helper.
07

Engineering reference: the event RSVP manager architecture

Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Lambda inventory, IAM scopes, the conditional-write capacity logic, EventBridge Scheduler config, and the DynamoDB schemas.

What is an event RSVP manager?: A small serverless system that runs the guest list for a small event. People register through a simple form; it confirms each RSVP by email, sends timely reminders before the date, handles cancellations, runs a waitlist that auto-offers a freed spot to the next person, caps capacity so the event never oversells, and gives the host a live headcount. Guests can confirm, cancel, or claim an offered spot straight from the email.
How much does it cost to run?: About $2.40/month for a typical event of around 200 guests. The fixed cost is essentially zero. The variable cost is dominated by the emails the system sends — one confirmation per RSVP, a couple of reminders each, plus waitlist offers — all through SES at $0.10 per thousand. Lambda, DynamoDB, and EventBridge Scheduler add up to pennies. A 50-guest event lands near $0.80; a 1,000-guest conference lands around $9.
Which AWS services does it use?: Lambda (Python 3.14, arm64) with Function URLs for the register, confirm, and cancel links, EventBridge Scheduler for reminders and waitlist-offer timeouts, DynamoDB on-demand (with a conditional write that enforces the capacity cap), S3 (with versioning), SES inbound + outbound, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) only for the post-event thank-you note and a host Q&A helper. No API Gateway, no NAT Gateway, no always-on compute.
How does it stop the event from overselling?: Every seat is claimed by a single conditional write to DynamoDB that only succeeds if the live confirmed count is below the cap. Two people clicking “confirm” at the same second can’t both win the last seat — the database refuses the second write, and that person is offered the waitlist instead. The cap is the one number the whole system defends.
How does the waitlist work?: When someone cancels, the freed seat is offered to the first person on the waitlist — not given, offered. They get an email with a claim link that holds the seat for a set window (default 6 hours). If they claim it, they’re in. If the window passes with no claim, the offer expires and the seat rolls to the next person in line automatically. Nobody is ever silently skipped, and a stale offer never blocks the seat forever.
Does it respect quiet hours?: Yes. Reminders and waitlist offers never go out between 9pm and 8am local time by default. A message that would land in the quiet window is deferred to the next morning by a one-off EventBridge Scheduler rule. The one exception is a time-critical waitlist offer where the claim window would otherwise close overnight — those can be allowed through by a host setting, because a missed seat is worse than a late-night email.
Does the host have to watch a dashboard?: No. The host gets a live headcount link that always shows confirmed, waitlisted, and open seats, plus a short daily summary email in the run-up to the event. The system runs itself; the host only steps in to change the cap, close registration early, or message the whole confirmed list. Every change is recorded in the ev-audit table so the guest list is reconstructable after the fact.

All posts

Frequently asked questions

Other series