Drop / raffle launches, how does queue management and 1-per-customer enforcement work?

Three components, wired together natively in Magento:

• Waiting-room queue, customer hits the drop URL, gets assigned a position number + ETA. Queue is bounded (typically 50k slots) and randomized within 5-second windows so refresh-spam doesn’t jump the line. Cloudflare Waiting Room (~$0.20 per 10k sessions) or Akamai Queue-It (enterprise) sits in front. Native Magento module manages the slot release at the rate the backend can handle (~200 orders/sec on a tuned 4-node setup).
• Lottery selection (raffle), for ultra-limited drops (Travis Scott Jordan 1, Yeezy Slide, etc.) you skip the queue and run a raffle window (24-72h). Customers enter, weighted by Discord tier + past order history + Twitter engagement score. At raffle close, winners are picked via cryptographic randomness (e.g. random_bytes seed from drand.love) so customers can verify fairness. Winners get a Stripe authorization hold (deposit-to-secure); charge only fires when they confirm.
• 1-per-customer enforcement, layered fingerprint. Email, payment fingerprint (Stripe payment_method ID hash), shipping address fingerprint (normalized + soundex), device fingerprint (FingerprintJS Pro), Discord OAuth ID. Any of these matching a previous winner → blocked. Same pattern Supreme runs every Thursday at 11:00 NYC time.

Stock reservations at cart, payment-vault tokenization, Cloudflare cache purge at the instant of go-live. No double-sells, no “charged but out of stock” refunds.