How WebJi® Scaled an Indian D2C Fashion Store Through 15,000 Concurrent Flash-Sale Shoppers
An Indian D2C fashion brand’s WooCommerce store held 15,000 concurrent shoppers during a Diwali flash sale after moving to a WebJi® cloud tier with dedicated Redis, queue-backed payment webhooks and a CDN. Checkout answered in about 420ms, availability was 99.99% for the window and no carts were lost to infrastructure.
For store owners planning a festive or flash sale who want to see which hosting changes held checkout steady at peak.
Jaipur · IN
- In business
- 21+ yrs
- Reply time
- <60 min
- Clients
- 12K+
- Billing
- INR + GST
Last editorial update: 14 November 2026. Prices follow the dated sources on this page; checkout confirms current charges.
What did the D2C fashion store need from its hosting for the Diwali flash sale?
The store needed its WooCommerce checkout to stay fast and its payments to stay accurate while thousands of shoppers arrived in the same few minutes of a Diwali flash sale. The sale peaked at 15,000 concurrent shoppers, a load its existing hosting had never carried.
The brand is an Indian direct-to-consumer fashion label selling through its own WooCommerce store. Flash sales concentrate a festival’s demand into a short window, so a slow minute costs more than a slow day. The brief had two tests: carts must not drop, and no customer should be charged twice.
Why would the store’s original hosting have failed under flash-sale load?
Pre-sale rehearsals on the original commodity shared hosting showed checkout responses climbing past two seconds at only a few thousand concurrent sessions. At the expected peak that would have meant abandoned carts long before the server actually went down.
- Shared CPU: PHP workers competed with other accounts on the same server, so capacity was unpredictable exactly when it mattered.
- Database pressure: every product, session and cart read went to MySQL, which slows first as visitors multiply.
- Duplicate webhooks: payment gateways retry a notification when they do not get a quick reply, and slow endpoints were occasionally recording the same payment twice.
Which architecture did WebJi® deploy for the flash sale?
WebJi® moved the store to an isolated cloud tier with a dedicated Redis object cache, queue-backed payment webhooks with idempotency keys and a CDN for static files, then rehearsed the sale twice. Each layer removed one specific bottleneck found in the baseline.
| Layer | Deployed | Problem it removed |
|---|---|---|
| Compute | WebJi® cloud tier (family from ₹5,900 a month before 18% GST) | Unpredictable shared CPU for PHP workers |
| Object cache | Dedicated Redis | Repeated catalogue and session reads hitting MySQL |
| Payment webhooks | Queue-backed endpoints with idempotency keys | Double recording when gateways retried |
| Static files | Global CDN edge | Images and scripts competing with checkout for origin bandwidth |
| Rehearsal | Two staged load tests | Guesswork about real capacity before the sale |
Redis matters most on the pages a page cache cannot help: cart, checkout and account pages are personal to each shopper, so they must be built fresh, and an object cache makes that rebuild cheap. The Redis object cache guide explains the set-up.
How did queued webhooks prevent double charges?
The webhook endpoint now acknowledges the gateway immediately, places the notification in a queue and processes it once, using the payment’s unique ID as an idempotency key. A retried notification with an ID already processed is recognised and ignored.
The quick acknowledgement stops the gateway from retrying in the first place, and the key check makes any retry that still arrives harmless. Under load this kept webhook processing flat even when retries bunched together, because the order system never saw the same payment as new twice. Store owners using Indian gateways can see the plugin side in the Razorpay for WooCommerce guide.
What were the measured results during the sale window?
Through the peak of 15,000 concurrent shoppers the store answered in about 420ms on average, stayed available 99.99% of the sale window and lost no carts to infrastructure. The client renewed on the same stack for its next sale cycle.
| Metric | Rehearsal on old hosting | Sale on WebJi® cloud |
|---|---|---|
| Concurrent shoppers handled | A few thousand before slowdown | 15,000 at peak |
| Checkout response | Above 2 seconds | About 420ms average |
| Availability in the window | Not reached at full load | 99.99% |
| Carts dropped by infrastructure | Expected at peak | Zero |
| Duplicate payment records | Occasional on retries | None; processing stayed flat |
Window availability is a measurement for this sale, not the 99.9% monthly target in the WebJi® SLA.
What can another WooCommerce store copy from this flash sale?
Four habits transfer to almost any WooCommerce sale: cache objects rather than only pages, make payment webhooks idempotent, push static files to a CDN and rehearse at expected peak before the banner goes live. The server size is the part that changes from store to store.
- Freeze theme and plugin updates for the week before the sale, so the tested build is the build that runs.
- Lower DNS TTLs well ahead if the store is changing servers, and cut over away from the sale date.
- Measure checkout specifically; a fast homepage says little about a slow cart.
For year-round store hosting, compare WooCommerce hosting with cloud hosting, and see the other engagements on the case studies hub.
Frequently asked questions
What did the flash-sale engagement cost?
The stack was priced on the published cloud tiers, which start at ₹5,900 a month before 18% GST, plus a Redis instance. Exact INR figures depend on catalogue size and expected traffic, so they are quoted during scoping against your own workload sheet.
How long did the set-up take before the sale?
Two weeks, including both load rehearsals. The new stack ran alongside the existing store until cutover, so the live shop was never taken offline while the work was done.
Why not just buy a bigger shared hosting plan for the sale?
A larger shared plan still shares CPU with other accounts, and it does not fix database load or duplicate webhooks. Isolated cloud resources give predictable capacity, and the cache and queue changes address the code-level causes that extra disk space cannot.
Can the cloud tier be scaled back down after the sale?
Cloud tiers are billed monthly, so a store can discuss moving to a smaller tier after the festive season. Keep the Redis cache and webhook queue either way; they help on ordinary days too.
Last editorial update: 14 November 2026. Prices follow the dated sources on this page; checkout confirms current charges.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. Free migration* (subject to terms & approval), INR pricing and 24/7 email support in Hindi & English — average first reply under 60 minutes.