generated from bisco/codex-bootstrap
28 lines
1.2 KiB
Markdown
28 lines
1.2 KiB
Markdown
# ADR-0004: Use Email Confirmation for Reservations
|
|
|
|
Date: 2026-04-28
|
|
|
|
## Status
|
|
|
|
Accepted
|
|
|
|
## Context
|
|
|
|
Public visitors can request seats for a specific performance. The system needs a simple way to verify that the requester controls the provided email address before issuing a confirmed reservation and QR code.
|
|
|
|
The system also needs to avoid overbooking when multiple pending reservations exist for the same performance.
|
|
|
|
## Decision
|
|
|
|
Create reservations as `pending` first, then send an email confirmation link containing an opaque confirmation token.
|
|
|
|
A reservation becomes `confirmed` only when the confirmation link is opened and the backend validates the token. Final capacity validation happens during confirmation inside a database transaction. A QR code is generated only after successful confirmation.
|
|
|
|
## Consequences
|
|
|
|
- Visitors receive a clear confirmation step before the reservation is finalized.
|
|
- Mistyped or unreachable email addresses are less likely to consume capacity.
|
|
- Pending reservations do not guarantee seats.
|
|
- A visitor may lose availability if other reservations are confirmed before they open the confirmation link.
|
|
- The booking flow depends on email delivery working reliably enough for the audience.
|