Skip to content

How would you add a fair waiting room for a large sale?

1 min read · main part only; folded sections are optional

After this you can answer: How would you add a fair waiting room for a large sale?

Fairness is a product decision: arrival order, a randomized draw or a priority group produce different outcomes. Decide whether reconnects retain position and whether an account may hold multiple places. Do not claim FIFO fairness without defining the identity and timestamp authority.

A proposed admission service would persist queue state and bind tokens to sale, expiry and an identity or session. Token verification belongs before expensive booking work, with bounded replay rules and a documented response when the waiting-room service is unavailable. A copied token must not grant unlimited admission.

Rate the release against measured database capacity, not simply current API CPU. Cap retries and provide backoff so rejected clients do not amplify load. Existing rate limiting controls repeated requests and the inventory gate rejects some sold-out work; neither supplies ordered admission or position state. The waiting-room state, UI and admission-token validation are proposed only.

Does admission reserve seats?
No, unless a separate reservation protocol explicitly does so. Users admitted near sell-out can still receive a booking conflict.
Would you fail open during a waiting-room outage?
That preserves access but can overload the booking system. Choose the availability trade-off ahead of a sale and keep a bounded emergency admission rate.
How do you prevent bots?
Use layered identity and abuse controls, while considering shared networks and accessibility. A token signature prevents forgery, not mass account creation.

Read the path chapter, select the relevant map piece →, then inspect apps/api/src/services/booking-inventory.ts → createGatedBooking.

Read this book online: https://book.theversehub.in/