Waitlist handling
Why it matters
When a slot reaches capacity and the system throws an unhandled database constraint violation or returns an HTTP 500, the customer receives no actionable information: they cannot retry a different slot, join a waitlist, or understand what happened. An unhandled capacity error produces the same symptom as a server crash from the user's perspective. Even without a formal waitlist feature, returning a structured 409 with a descriptive message gives the frontend enough information to guide the user — a minimum viable response to a predictable state the system already knows about.
Severity rationale
Low because the primary impact is poor user experience and support volume, not data corruption or security exposure, when capacity limits are reached.
Remediation
Handle the capacity-exceeded case explicitly in your booking handler (e.g., src/app/api/bookings/route.ts). Return a 409 with a structured body so the frontend can render a useful message.
if (currentCount >= slot.maxCapacity) {
// If waitlist is supported:
if (req.body.joinWaitlist) {
await db.waitlistEntry.create({ data: { slotId, userId } });
return res.status(202).json({ status: 'waitlisted' });
}
return res.status(409).json({
code: 'SLOT_FULL',
message: 'This slot is fully booked.',
});
}
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Booking Flow & Lifecycle Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · reliability.fault-tolerance — Fault Tolerance — graceful structured response when slot reaches capacity
Taxons
History
- 2026-04-18·v1.0.0·Initial import from booking-flow-lifecycle·automated