build.allanninal.dev

Part 3 of 7 · Event RSVP manager series ~5 min read

How an RSVP reminder gets scheduled

The moment a guest confirms, the system works out exactly when to remind them — a week before, a day before, the morning of — and books each one as its own timed job. It doesn’t poll a list every hour looking for who’s due; it sets an alarm for each reminder and walks away. The whole decision is plain date arithmetic. The reminder schedule lives in the host’s settings, where it can be changed without a developer.

Key takeaways

  • When a guest confirms, the system books their reminders as one-off EventBridge Scheduler rules.
  • The schedule lives in the host settings — the default is a week out, a day out, and the morning of.
  • Each send time is computed from the event date, then nudged out of quiet hours.
  • A reminder already past (the guest confirmed late) is simply skipped, not sent stale.
  • No always-on poller. Each reminder is its own alarm; the system sleeps in between.

The scheduling decision, per reminder

Scheduling decision per reminder when a guest confirms A vertical decision flow diagram. At the top, an input box "Confirmed guest" with the guest's name, email, the event date, and the reminder schedule. Below that, a step "Compute each send time" — the event date minus each offset in the schedule, in the configured timezone. Below that, a check "Send time already past?" — if yes, route to "Skip" (don't send a stale reminder). If no, continue. The next step "Look up reminder schedule" — pulls the offsets from the host settings; the default is seven days, one day, and the morning of. The next step "Which reminder is this?" — picks the week-out, day-out, or morning-of slot based on the offset. The next step "In quiet hours?" — checks the computed send time against the quiet-hours window from the settings; if it lands overnight, it's nudged to the next morning. Each terminal box — Skip, Week-out, Day-out, Morning-of — books a one-off EventBridge Scheduler rule at the final send time that will invoke the messenger to send that reminder. A note at the bottom: the schedule lives in the host settings — change an offset and new confirmations use the new value. Confirmed guest name · email · event date Step 1 Compute each send time event_date − offset (TZ) Step 2 Send time already past? guest confirmed late? Step 3 Look up reminder schedule default → [7d, 1d, morning] Step 4 Which reminder is this? past → skip morning-of → morning slot Step 5 In quiet hours? nudge to next morning Skip send time passed Week-out seven days before Day-out one day before Morning-of morning of the event if yes past morning week day before The schedule lives in the host settings — change an offset and new confirmations use it.
Fig 3. The scheduling decision, per reminder, the moment a guest confirms. Five steps decide which timed jobs to book. The host settings hold the schedule; the system only computes the times and books the alarms.

Why one-off alarms instead of a poller

There are two ways to send reminders. One is a poller: every hour, wake up, read the whole guest list, and ask “is anyone due a reminder right now?” That works, but it runs constantly whether anything is due or not, and it has to be careful not to send a reminder twice. The other way — the one used here — is to set an alarm for each reminder at the moment the guest confirms. When the guest clicks confirm, the system computes the three send times and books three one-off jobs through EventBridge Scheduler, each pointed at the exact minute it should fire.

The alarm approach is cheaper (nothing runs in between) and simpler to reason about (each reminder is one job that fires once). When the job fires, it invokes the messenger to send that one email, then the job deletes itself. There’s no list to scan, no “did I already send this” bookkeeping on a poll loop — the alarm either fired or it didn’t.

Computing the send times

The schedule is a short list of offsets in the host settings. The default reads, in plain words: “Remind seven days before, one day before, and the morning of.” For each offset, the system subtracts it from the event date and time, in the event’s configured timezone, to get a target send time. A 6pm event on the 20th gives a week-out reminder on the 13th, a day-out on the 19th, and a morning-of at, say, 9am on the 20th.

Two small adjustments keep the times sensible. First, the morning-of reminder is pinned to a friendly hour (9am by default) rather than literally “the event time minus zero,” because a reminder at the exact start time is useless. Second, any computed send time that lands inside quiet hours is nudged forward to the next morning — covered just below.

Quiet hours: never a 2am reminder

The host settings include a quiet-hours window, 9pm to 8am local by default. Before a reminder job is booked, its send time is checked against that window. If the time falls inside quiet hours — for instance, a day-out reminder for a late-night event computing to 11:30pm — the send time is moved to the start of the next morning’s business window. The guest gets their reminder at 8am instead of nearly midnight. The job is booked at the nudged time, so quiet hours are enforced once, at scheduling, and never need rechecking when the job fires.

Quiet hours apply to reminders and waitlist offers, not to the immediate confirmation email — that one is a direct response to the guest’s own click, so it always goes out right away regardless of the hour.

Late confirmations and skips

Not every reminder applies to every guest. Someone who confirms two days before the event has already missed the week-out window. Rather than fire a stale “your event is in seven days” email a week too late, the system checks each computed send time against the current time and simply skips any that are already in the past. The late-confirming guest still gets the day-out and morning-of reminders; they just never get the week-out one. No stale emails, no awkward timing.

Each booked reminder is also recorded against the guest in DynamoDB, so if the guest later cancels, the system knows exactly which pending reminder jobs to delete — the subject of the next post. A cancelled guest must never get a “see you tomorrow!” reminder.

Next post: how a cancellation frees a spot — releasing the seat, cleaning up the guest’s pending reminders, and handing the freed seat to the waitlist.

All posts