Nobody Can Promise You a Peak Day. You Can Know Where It Will Be Decided.

After last year’s sale, the business doubled its servers. The bill doubled with them.

This year the sale opens, and the product pages are quick. Then customers reach checkout, and wait. The new servers are barely working. The queue is somewhere else.

It is in a piece of code written nine years ago, which reserves stock for one order at a time. While it deals with one customer, every other customer stands behind them. Ten servers or a hundred, it is still one at a time.

What We Found

We looked at software that met more than its design allowed, a published ceiling for a large booking system, and one survey of mid-size firms. None of it is about shops: the retail research behind this article holds no evidence on shops slowing at peak times.

A design limit does not show until the day it is reached. This is an airline, not a shop, and a storm, not a sale. At a large US airline, crew-scheduling software about two decades old could not keep up with the changes after a winter storm in 2022, and thousands of flights were cancelled. The limit was in how it worked, not in how much hardware it had.

A ceiling can be stated. 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 for one point only: a limit can be known before the day it matters.

Old technology is said to hold mid-size firms back. In one vendor-sponsored survey of a few hundred leaders at mid-size US and UK manufacturers, retailers and wholesalers, about seven in ten agreed that outdated technology is holding them back. The survey is about technology in general, not peak days.

What Knowing the Limit Opens Up

A list of an old shop’s limits is usually seen as the technology team’s homework. Our reading is that it frees more than that.

• The money goes to the limit. Spending is tied to the part that holds sales back, not spread across servers that were never the problem.
• The fix has a test of “done”. A rebuilt part can be checked, function by function, against the part it replaces, before it takes a single real order.
• The peak day gets a plan. With the weak parts named, your own team can write down who watches what and who decides, before the campaign goes out.

This is our reading. It is not a measured market figure.

Three Ways to Prepare for the Next Sale, Weighed

Option	When it fits	What it risks
Double the servers again	The last slow sale was a plain shortage of capacity, and the shop’s parts can share the work	If the limit is one part’s design, the bill rises and the queue stays where it was
Commission a load test and act on the result	The shop is already well understood, and the firm wants a number before the sale	A test shows where the shop slows, not why, and leaves little time to act before the peak
Read the code, rebuild the part whose design is the limit module by module, and prove each module does what the old one did; your team then tests and plans the peak	Slow sales keep coming back after capacity was added	It takes stages and costs money before anything is faster. Removing one limit shows the next. It does not by itself show how the shop behaves at peak volume

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the first module is rebuilt, and fill in as each module is accepted.

Measure	Typical starting point	Where it should be	How it is checked
Each part of the shop, with its known limit	Not listed; “the load”	Every shared part listed, with how it is built and what waits on it, as read from the code (not from a load test)	The specification and the risk register
The part that sets the ceiling	Found on the day, if at all	Named before the peak, with the reason	The risk register
The limiting part rebuilt	Untouched, because nobody dares change it	Rebuilt module by module beside the old shop, each module shown to do what the old one did	The traceability matrix, module by module
What must never go wrong	Assumed	Written down for the rebuilt part: no item sold twice, no payment taken twice	The specification, and the traceability matrix
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
A peak-day plan	In one engineer’s head	Written, and owned by your team: who watches what, what is switched off first, who decides	Your plan; we take no part on the day

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.

A small part of the finished list might look like this.

Part of the shop	Its known limit, as read from the code	Status
Stock reservation at checkout	Locks the whole stock table for each order, so orders take turns	Stage 1: rebuilt beside the old shop; traceability matrix accepted; load test arranged by the retailer
Product pages	Built to run as many copies side by side	No rebuild needed
Payment step	Inside a payment company’s service	Outside our reach; the payment company’s matter

The rows above are an illustration, not taken from a real shop.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about the shop and the servers bought since 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.
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.
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. A traceability matrix links every old function to its replacement. 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 above. As each module is accepted 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.

This has a price. The part that sets the ceiling is usually the most delicate code in the shop. When one limit is removed, the next narrowest part becomes the limit, so the work may not end with one module. A traceability matrix shows that the new part does what the old one did; it does not show how it behaves under full load. We do not run load tests, our assessment does not include one, and we promise no uptime, no speed and no capacity. We do not monitor, run or host your shop, and we are not on call on the day of a sale; your own team or agency runs it. If the limit sits inside a packaged or hosted shop platform, or a payment company’s system, we cannot reach it: we do not install, upgrade, move or choose shop platforms. We have no published case of this work for a retailer.

At the end you hold the specification, the list of parts with their known limits, and the traceability matrix and code for every module we rebuilt. The load test, the peak-day plan and the decision on the next limit are your team’s.

What changes for the business:

Role	What they gain
CEO	The one old piece of code that set the limit is rebuilt, and the next limit is known.
CTO or CIO	The bottleneck is replaced by code built to serve many customers at once, checked against the old for correctness.
CFO	Spending on servers that did not help can stop.
COO	The rule that no item is sold twice is written down and checked, function by function, in the rebuilt stock step.
Head of marketing	The checkout step that made customers queue is rebuilt, and the team goes into the sale with a plan everyone knows.

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

The case	What IOanyT does
A large US airline’s crew-scheduling software, about two decades old, could not keep up after a storm in 2022, and thousands of flights were cancelled.	Our part is far narrower, and in another industry. For an application a retailer built, we find the part whose design sets the limit and rebuild that part alone, with the old system still running. We do not say what would have helped the airline.
Indian Railways’ passenger reservation system: about 25,000 tickets per minute, as the railway minister told the Lok Sabha in August 2025.	We do not work on systems of that kind, and we make no comment on it. For a retailer’s own application, we read the code to find which part is likely to set it; 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. We cannot promise you a peak day, and we will not; we can show you where it will be decided.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →