Problem Statement: Product Waitlist at Drop Scale
Problem Statement: Product Waitlist at Drop Scale — product waitlist system design
Problem Statement: Product Waitlist at Drop Scale
Design a product waitlist for limited-edition commerce: shoppers join when a SKU is sold out or not yet released, and receive a time-boxed purchase invitation when inventory allocates to them. The waitlist is the bridge between a demand spike of millions and an inventory of hundreds — and its whole job is to hand out those few units fairly, without overselling, and faster than bots can game it.
Why this is not a mailing list
Apple's product pages queue millions for a single iPhone color; Nike SNKRS runs draw-plus-waitlist hybrids; Supreme sells out in seconds and then backfills cancellations in waitlist waves. The failure mode to name out loud is treating the waitlist as a mailing list — a list of emails with no purchase tokens, no inventory coupling, and no expiry windows. That design oversells the moment two notified shoppers click at once.
The blast-radius intuition makes it concrete: if you "just email everyone when it restocks," 500K emails for 200 units destroys brand trust and melts your origin. The right model invites in waves proportional to stock plus a no-show buffer, and every invite carries a short-lived token bound to a reserved unit.
What the system must guarantee
A waitlist entry is worthless without three things attached: a stock signal (real available units, not a guess), a hold (the unit is reserved the instant the invite goes out), and a short-lived purchase token (the invite expires so a no-show returns the unit). Get those three right and the rest is scale; get them wrong and you either oversell or strand inventory.
The architecture should flex per campaign.fairness_model — FIFO for one drop, a lottery for the next — without rewriting core storage. That one requirement, stated early, shapes every later decision.
Key Highlights
- •A waitlist bridges a demand spike of millions to an inventory of hundreds — allocate the few units fairly, without overselling, faster than bots can game it
- •Not a mailing list: every entry needs a stock signal + an inventory hold + a short-lived purchase token; emailing 500K people for 200 units oversells and melts the origin
- •Invite in waves proportional to stock + a no-show buffer; the purchase invitation must be atomic with the stock reservation
- •Architecture flexes per campaign.fairness_model (FIFO vs lottery) without rewriting core storage — Apple/Nike/Supreme each pick a different model
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I'll quantify Problem Statement: Product Waitlist at Drop Scale with join RPS and invite fan-out, not vague 'millions of users'."
- "Invites always follow inventory holds; tokens expire to limit scalping."