During a flash sale there is not only high traffic on the website but a lot of traffic arrives in the same sixty seconds.

When Flipkart's Big Billion Days opened in October 2026, the company reportedly had around 6.3 million shoppers on the platform at once. 

It is only fair to wonder how these websites keep up with such huge numbers all at once? How do they not crash? For a big company like Flipkart or Amazon people may assume that they have a lot of money so they probably have huge data centers and storage and computing capacity. But let me tell you this, it's not that. In fact, even a small company can pull this off without having to invest in huge infrastructure and hardware and then see it sit idle the entire year, until the next sale comes. 

Here is how the big players prepare, and which of their moves you can copy without their budget.

Why do websites crash during flash sales?

Before we begin this topic it is really important to understand what happens behind the scenes. Why do websites crash during a flash sale? The answer is the sudden load. Average traffic hides the real problem. A sale sends thousands of people to the same few pages and the same few database rows within seconds.

The usual pressure points:

• The spike arrives in seconds, faster than most servers can start up

• Reads pile onto a few pages, like the deals page and the product you promoted

• Writes pile onto inventory and checkout, where every order touches the same stock rows

• Third parties hit their limits, such as payment gateways and OTP SMS providers

How big are the spikes in Indian e-commerce right now?

Big enough to be a useful benchmark. A few data points from the October 2026 festive season:

• Flipkart reportedly saw 6.3 million concurrent users around the opening of Big Billion Days

• Amazon's Great Indian Festival opened to all customers on 8 October, and its opening phase reportedly doubled order volumes

• Meesho's Mega Blockbuster Sale orders rose about 75 percent year on year on day one

• Online festive sales are projected to grow by as much as 29 percent this season

How do the big brands prepare before the sale starts?

They treat the sale as a project that starts weeks ahead, not a day that happens to them. The preparation is mostly unglamorous.

• Pre-scale capacity before the doors open, instead of waiting for traffic to trigger it

• Load test with realistic spikes, not a gentle ramp

• Freeze risky releases in the days before, since a late deploy is a common cause of sale-day outages

• Rehearse rollback, so a bad change can be reversed in minutes

• Staff a war room with the right people on call, and a clear owner for every system

Why not just rely on autoscaling?

Because autoscaling reacts after traffic arrives. New servers take minutes to start, and a flash sale can outrun that in under one. Autoscaling is good at handling surprises on top of a plan. It is not a substitute for the plan.

So the sensible pattern is to pre-scale to your expected peak, then let autoscaling cover the overshoot.

What do they do to protect the database and checkout?

They keep as much traffic as possible away from the parts that are hard to scale.

• CDN and edge caching for images, scripts and static pages, so these never reach your servers

• An in-memory cache, like Redis, for read-heavy lists such as top deals

• Queues for slow work, so order confirmations, emails and SMS happen after checkout instead of blocking it

• Careful inventory handling, since stock is the one thing many buyers fight over at once

At the top end, the numbers are huge. Flipkart's published engineering account with Aerospike reported its in-house database platform sustaining 95 million transactions per second during Big Billion Days in 2024. That is the scale of the problem the giants solve, and a reminder that the data layer matters as much as the web servers.

How do they stop one slow service from taking the whole site down?

By deciding in advance what to switch off. Recommendations, reviews and personalised widgets are nice to have, and checkout is not. If load gets dangerous, good teams degrade the extras first and protect the path to payment.

This is worth writing down before the sale, not working out at midnight with the dashboard turning red.

What can a smaller brand copy from the giants?

Most of it, in a smaller form. You do not need Flipkart's budget. You need cloud infrastructure you can resize on a schedule, plus the habits above.

What should your last 48 hours before a sale look like?

Work down this list in order.

1. Run a load test at several times your previous peak, and fix what breaks

2. Schedule the pre-scale, and confirm it actually triggers

3. Warm the cache with your promoted products and pages

4. Check payment gateway and OTP provider limits, and ask for increases if needed

5. Freeze code changes except for emergencies

6. Write the rollback plan and test it once

7. Decide which features switch off first if load spikes

8. Name an on-call owner for every system, and a person who talks to customers

What does this look like for a small D2C brand?

Here is an illustrative case. A D2C brand normally has about 100 people on its site at once. It announces a two-hour flash sale to its email list and expects around 20 times that in the first ten minutes.

Without a plan, the site slows down in the first minute, checkout times out, and shoppers who were ready to buy leave. With a plan, extra servers were scheduled the day before, images and the deals page sit behind a CDN, order emails go through a queue, and the team knows to switch off product recommendations if load climbs. Same sale, same traffic, very different outcome.

The difference is not the budget. It is a one-page plan and a load test run on a quiet afternoon.

Where this leaves you

Sites stay up during flash sales because someone planned for the first minute, not because they had unlimited servers. Pre-scale, cache what you can, queue slow work, decide in advance what to sacrifice, and test the whole thing before the day. Do those five things and you will handle a spike far larger than the one that took your site down last time.

A few quick questions people keep asking about this

How much extra capacity should I provision? 

A common rule of thumb is to plan for at least double your previous sale's peak, then confirm it with a load test. Your own numbers matter more than any rule, so test before you trust it.

Is a CDN enough on its own? 

No. A CDN takes pressure off static content, which is a big win, but your login, cart and checkout still run on your own servers and need real capacity behind them.

What usually breaks first? 

Often not your own servers. Payment gateways, OTP SMS services and shipping APIs have their own limits, and they are easy to forget until they fail in the middle of a sale.