A drop is a small, time-bound moment of intense customer attention. Two thousand people refresh the same URL at the same second. A few hundred buy. A few thousand are disappointed. If you're the engineering team behind the drop, the next sixty seconds either build a brand or break one.
We've now run 380 drops on the Polluxa drops engine. Some of them sold out in 22 seconds. Some of them stretched over 14 minutes. One particularly memorable one survived a real DDoS attack while still moving inventory. This is a tour of what's actually happening under the hood, and where we got it wrong before we got it right.
Why a regular checkout doesn't work for drops
A regular ecommerce checkout assumes a steady-state load profile. Sessions arrive over hours. Carts age over minutes. Stock decrements happen in a fair, parallel way. Inventory eventually balances.
A drop violates every one of those assumptions. The entire month's customer demand arrives in the first thirty seconds. Carts age in milliseconds. Stock decrements happen in a brutal serial way — the first ten buyers should win, the last ten buyers should be honestly told the drop is sold out. Inventory must not balance via apologies. Each "we oversold, please refund" message is a tiny brand-equity tax that customers don't forget.
So the drops engine is a different machine from regular commerce, sharing only the catalog and the customer record.
The four primitives
The drops engine has four core primitives. Each one looks innocuous on its own. Together they prevent every failure mode we've seen.
The queue. When a drop opens, all incoming traffic hits a stateless queue front-end backed by a single canonical Redis Sentinel. The queue gives each session a deterministic position. Position is a function of arrival timestamp and a per-session entropy that prevents bots from claiming "I was first" advantages.
The token. A position in the queue isn't a license to buy. It's a license to receive a buy token, valid for a short window (typically 90 seconds). The token is the thing that decrements stock atomically. No token, no buy.
The reservation. Once a token is exchanged for a reservation, the inventory unit is committed. The reservation has a TTL of about 5 minutes for the payment to clear. If payment fails or TTL expires, the unit goes back into the pool.
The payment guarantee. For the highest-tier drops, the system can require pre-authorized payment cards before issuing a token. This filters out window-shoppers and locks in payment intent before stock leaves the pool.
Fairness, the part nobody warned us about
"Fair" is harder than it sounds. A naive first-come-first-served queue would punish anyone with a slower internet connection. A purely random queue would feel unfair even when it wasn't. A geographic queue would tilt against rural users.
We landed on a hybrid. Within a 200-millisecond bucket of arrival, the queue order is randomized. Across buckets, earlier is genuinely earlier. The result is that the first 50 people in the door are random within "the first half-second," which is the resolution any human can perceive. Below that, nobody can tell who came first anyway.
The bonus property: this defeats most bot strategies. The bots optimize for first-millisecond arrivals, but a bot at millisecond 1 and a human at millisecond 199 are randomized into the same bucket. Bots no longer dominate.
Fair within a 200-millisecond bucket of arrival, ordered across buckets. The result is that nobody can tell who came first within the first half-second — and that defeats most bots.
Anti-bot, the unsexy part
Most "anti-bot" features are theatrical. Captchas annoy humans more than bots. IP throttling fails when the bots are residential proxies. We landed on three layers that actually work.
Behavioral fingerprinting at the queue front-end catches the loudest bots cheaply. Pre-auth payment requirements catch buyers who don't have an actual card on file with their identity. And per-account purchase limits — usually 1 unit per drop — make scalping fundamentally less profitable, because resellers can't operate at scale.
We don't claim to catch every bot. We claim to make the bots' margins too thin to be worth running, which is the actually-useful threshold.
The decision we'd reverse
Early on, we let creators configure whether their queue position would be shown to the user. About 70% of creators chose "yes, show position." It seemed transparent. It was a mistake.
Showing position turns a queue into an anxiety machine. Customers refresh the page obsessively. They share screenshots on Twitter complaining that they were #4,200 in line. They check back every 30 seconds. The user experience is miserable, the brand sentiment after the drop is worse, and the queue itself takes more load from the refreshing.
We now strongly default to "show a friendly waiting state, not your position." The drops that ship with this default have measurably better post-drop sentiment scores. We should have made the call earlier. We were optimizing for "transparency" when we should have been optimizing for "anxiety reduction."
What's next
Multi-region drops. Right now a single drop runs on a single region. We want global creators to be able to run one drop across IN, GCC, SEA and US simultaneously, with regional inventory split. That's a 2026 H2 project — the tricky part isn't the engineering, it's the fairness story across time zones. Should a 9 AM ET drop disadvantage Tokyo customers because it's the middle of their night? We're still debating internally.
If you're running drops on something else and want to see how Polluxa handles your worst-case load, talk to creator commerce — we'll do a stress-test on a copy of your last drop's traffic profile.