Sale Days Your Shop Cannot Hold. More Servers Are One Answer of Four.

Your shop runs on four servers. It has run on four servers for six years.

On an ordinary Tuesday they sit mostly idle. On the first day of the sale they are overwhelmed within minutes. Last year you rented two more for the week, and they caused a fault of their own.

This year marketing has a plan that should bring twice last year’s visitors. Your hosting company says more servers will take three weeks to arrange. Nobody can say whether more servers were the answer last time.

What We Found

We looked at the public record on systems meeting more than they were built for and on how firms see their technology, and at the one result of this kind IOanyT has published.

The retail research behind this article holds no evidence on shops slowing at peak times: no named retailer, no figure for sales lost. The outside facts below are labelled so.

We have given one shop room to grow, by moving its hosting. In IOanyT’s own published cloud migration for ITCan, an e-commerce client, capacity went from 300 to 30,000+ concurrent users (people using the shop at the same moment). It was a move of hosting to AWS. It was not a replacement of old code, and it is one client’s result, not a forecast for another shop.

A ceiling can be stated, even for a very large system. This is a railway, and we pass no judgement on it. In a written answer in the Lok Sabha in August 2025, the railway minister said that “the booking capacity of the current PRS”, the passenger reservation system of Indian Railways, a government body, “is about 25,000 tickets per minute”. We use the figure only to show that a limit can be known in advance. In most old shops, nobody knows theirs.

Firms say their technology holds back their online sales. In one vendor-sponsored survey of a few hundred leaders at mid-size US and UK manufacturers, retailers and wholesalers, more than nine in ten said their existing technology limits their ability to succeed in online selling, and about seven in ten agreed that outdated technology is holding them back. The sponsor sells commerce software, and the research behind this article judged the first figure likely to be overstated. The survey is not about peak days.

Sale Days the Shop Cannot Hold

A slow sale is usually discussed as a technology problem. Our reading is that it is first a business problem: the sale is where the year’s work is meant to pay off.

The campaign is held back. When nobody knows what the shop can take, the sale email goes out in batches through the night, and the last batch arrives after the best lines have gone.

Capacity is bought blind. Fixed servers give the same capacity on the busiest day as on the quietest. Size them for the peak and pay all year; size them for the average and turn customers away on the days that matter.

The wrong part gets the money. If the part that gave way serves one customer at a time, more servers do not reach it, and the queue stays where it was.

This is our reading of the evidence. It is not a measured market figure, and we do not put a value on a sale day here. That figure has to come from your own business.

Four Ways to Answer a Sale Day, Weighed

Option	When it fits	What it risks
Add servers or a bigger hosting plan	The limit really is a shortage of capacity, and the shop’s parts can share the work	It does nothing for a part that serves customers one at a time. Servers bought for the peak sit idle the rest of the year
Move the hosting to the cloud, with capacity that rises and falls with demand	The shop’s parts can run as many copies side by side, and the firm is free to use the cloud	A hosting move is a project with its own risk and should not be made just before a peak. A busy day in the cloud costs more than a quiet one. It does nothing for a part that serves customers one at a time
Replace the whole shop	The shop is beyond saving, and the firm can carry a long project	Nobody yet knows which limit the old shop had, so the new one may repeat the design
Read the code to find the part whose design is the limit, then rebuild that part module by module	Slow sales keep coming back, even after servers were added	It costs money before anything is faster, and removing one limit shows the next

The honest costs. Cloud capacity is paid for by use, so a very busy day costs more than a quiet one. A hosting move should not be made in the weeks before a peak. And when one limit is removed, the next narrowest part becomes the limit, so the work may not end with one module.

Where You Are Now, and Where You Should Be

Before the next sale is planned, we would set a benchmark for the decision.

Measure	Typical starting point	Where it should be	How it is checked
Answers considered after a slow sale	One: more servers	Four, each weighed against the part that gave way	The cost comparison
The limit behind the last slow sale	Called “the load”	Named: a shortage of capacity, or a part built to serve one customer at a time, as read from the code	The risk register
The cost of a sale day	The hosting bill alone	Servers, staff time, campaigns held back and the cost of a busy day in the cloud, in one place	The cost comparison
The size of one commitment	A new shop or a whole hosting move	One module, with the freedom to pause after any accepted module	The staged plan
Behaviour at peak volume	Learned from customers on the day	Measured before the peak in a load test your team arranges; we claim no figure	Your own load test, outside our work

The starting points above are what we expect to find. In an engagement they are replaced by your own position, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a retailer.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the shop and the last sale. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the code your shop runs on that your firm built or had built. It produces a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means the part whose design is the limit, rebuilt beside the old shop. We never do a single cutover. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

What you need to bring: a budget for the assessment; read-only access to the code once the assessment begins; whatever records you have of past slow days; someone from operations and finance to say what must never go wrong, such as an item sold twice; and your own team or agency to run the shop before, during and after every sale.

What we do not do: we do not monitor or run your shop, we do not host it, and we are not on call on the day of a sale. We promise no uptime, no speed and no capacity. We do not run load tests, and our assessment does not include one. A packaged or hosted shop platform’s capacity is its supplier’s matter: we do not install, upgrade, move or choose shop platforms. We do not secure or scan a shop. Our published cloud result was a move of hosting for one client; we have no published case of rebuilding a retailer’s old code.

What changes for the business:

Role	What they gain
CEO	The busiest days can become the best trading days, not a risk to the firm’s name.
CTO or CIO	A choice between more servers, a hosting move, a new shop and a rebuild, made on evidence and not at midnight.
CFO	Money for sale days goes to the answer that fits the limit, with the cost of a busy day known in advance.
COO	Operations knows which answer was chosen for the next sale, and what it changes for orders and dispatch.
Head of marketing	The campaign is planned around a shop whose weak point has been dealt with, not around a fear of sending it.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
Indian Railways’ passenger reservation system: about 25,000 tickets per minute, as the railway minister told the Lok Sabha in August 2025.	We make no comment on the railway and do not work on systems of that kind. For a retailer’s own application, we read the code to show which part is likely to set its limit, and rebuild that part if you approve; we do not measure the figure.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Before anyone buys more servers, we would find out whether servers were ever the limit.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →