Anyone who has ever run an e-commerce store through Black Friday knows the feeling. Zero hour. The promotion goes live. Thousands of users hit the server simultaneously. And in the best case, the store slows to a crawl. In the worst case, it goes down completely.
But "goes down" is too mild a phrase. Let's look at what actually happens inside.
The anatomy of an e-commerce store failure
A typical failure during a traffic spike does not look like a sudden blackout. It looks like a slow death.
The first symptoms appear subtly. Server response time grows from 200ms to 800ms. Users start refreshing pages because "something is not loading". Every refresh is a new request to the server. The server gets more and more requests, slows down even further, users refresh even more. This vicious cycle always ends the same way.
The database starts queuing queries. The connection pool is exhausted. PHP-FPM or Node cannot handle new requests and starts rejecting them. Nginx returns 502 or 503. Customers see a blank error page.
At this point you are not just losing sales from that hour. You are losing the trust of customers who just tried to buy something and got an error. You are losing the ad budget that generated that traffic. You are losing SEO positions because Google sees an unavailable page. And you are losing the time you have to spend firefighting instead of celebrating a successful campaign.
The cost of one hour of downtime for a large e-commerce store can reach tens of thousands of euros. The cost of downtime on Black Friday is often a multiple of monthly revenue.
This is not a problem you solve with better hosting. You can buy three times more resources and still have the same problem if traffic is spiky enough. Cloud auto-scaling helps, but has latency in the range of minutes, while your server goes down in seconds.
This is a fundamental architecture problem: unlimited number of users versus finite system resources.
An old solution, a new application
The solution is as old as queues in grocery stores. Instead of letting everyone in at once, you let X people in at a time, and the rest wait in line with information about their position and estimated wait time.
In the physical world this is obvious. IKEA does not let an unlimited number of customers in simultaneously. The queues outside stores on Black Friday are not a system failure, they are deliberate flow control.
In e-commerce, the same mechanism is called a virtual waiting room and is used by the largest sales platforms in the world during product launches, drops and flash sales.
That is exactly what we are building as DropReady.
Who already does this and why we did not buy it
The virtual waiting room market exists. There are players who have been doing this for years.
Queue-it is probably the best known product in this category. It handles Nike launches, Ticketmaster, government sites during vaccine registration. A solid product, battle-tested at millions of users. Price? From several thousand dollars per month upwards, depending on traffic. For enterprise that is a reasonable investment. For a small or medium e-commerce store it is an unacceptable cost.
Waiting Room by Cloudflare is an option available in Cloudflare Enterprise plans. An elegant solution if you are already using Cloudflare at that level. If not, another barrier to entry.
Fastly has similar functionality in its CDN. Again, enterprise pricing, enterprise complexity.
The common denominator of all these solutions: they are designed for companies that serve millions of users and have IT departments that can deploy and maintain them. For a PrestaShop store that does Black Friday once a year, none of these solutions makes economic or operational sense.
Beyond cost, all of the above solutions rely on WebSocket architecture, which requires maintaining a persistent, open connection throughout the entire time a user is waiting. With hundreds of thousands of waiting users, this means a massive, stateful server cluster. And it is fragile: a dropped mobile connection (riding a train, losing signal) means a user falls out of the queue.
So instead of paying for something oversized and architecturally fragile, we decided to build it ourselves. And since we are building it anyway, we are building it as a product we can sell to other stores that have the same problem.
What DropReady is
DropReady is a virtual waiting room for e-commerce stores. When traffic exceeds a defined threshold, new users are placed in a queue instead of hitting the store directly. They see their position in the queue, an estimated wait time, and are automatically let in when a slot opens up.
The store runs stable. Users know they are waiting, not that the site is broken. The server does not go down.
Why we are building this now
We have our own project, dealit.gg, an influencer marketplace launching soon. We expect the launch to generate a traffic spike in a short window and we need exactly this solution.
This is a classic "eat your own dog food" moment. Instead of buying an existing tool, we are building our own. And since we are building it anyway, we are building it as a product we can sell to others.
Tech stack and architecture
Backend: Go and KeyDB. Instead of burdening the system with fragile WebSocket connections, we built on a powerful in-memory engine and Adaptive Polling with Jitter. Go combined with fasthttp handles tens of thousands of requests per second at minimal RAM usage, completely stateless.
What does this mean in practice? A user on an unstable mobile connection does not fall out of the queue. The server does not maintain thousands of open file descriptors. The entire system scales horizontally with no stateful synchronization between nodes.
Integration: Early Intercept. We do not use a JS snippet pasted into the page that lets the server take the hit before it kicks in. We intercept traffic at the very edge of the client's infrastructure (3 lines in PHP, Node or Nginx), verify cryptographic Ed25519 tickets offline and offload the database 100%. The client's server never sees a request from a user who is still waiting in the queue.
What we plan to build in MVP
Minimum scope to test the product on dealit.gg:
Queue with Adaptive Polling, position and estimated wait time
Admin dashboard (on/off, concurrent user limit)
Early Intercept integration for PHP and Nginx
Basic stats (peak concurrent users, average wait time)
Nothing more. Billing, multi-tenant, customer panel — all of that comes after the product survives its first real traffic.
What comes next
The next posts in this series will be technical. Why Adaptive Polling beats WebSockets for this use case, what Ed25519 token verification looks like in PHP, and how we test the system under simulated load before the dealit.gg launch.
If you run an e-commerce store and the problem of traffic spikes sounds familiar, sign up for early access through the form on the DropReady page.
FAQ
What is a virtual waiting room and how does it work?
A virtual waiting room is a system that controls the flow of users to a website or application. When traffic exceeds a defined threshold, new users are placed in a queue instead of hitting the server directly. They see their position in the queue and an estimated wait time, and are automatically let in when a slot opens up.
How does Adaptive Polling differ from WebSocket in the context of a virtual queue?
WebSocket requires maintaining a persistent, open connection throughout the entire time a user is waiting, which with hundreds of thousands of waiting users means a massive, stateful server cluster and is fragile on unstable mobile connections. Adaptive Polling with Jitter allows the server to handle requests statelessly and immediately release resources, making the system resilient to dropped connections and easy to scale horizontally.
What is Early Intercept and why is it better than a JS snippet?
A JS snippet pasted into the page allows the client's server to generate HTML before the queue kicks in, meaning the server still takes the hit. Early Intercept captures traffic at the very edge of the client's infrastructure (3 lines in PHP, Node or Nginx) and verifies cryptographic Ed25519 tickets offline. The client's server never sees a request from a user who is still waiting in the queue.
Which stores and platforms is DropReady designed for?
DropReady is designed for e-commerce stores of any size that experience traffic spikes during flash sales, product launches or seasonal campaigns like Black Friday. The integration works with any platform, PrestaShop, Bagisto, WooCommerce or a custom Laravel solution, through 3 lines of backend code.