Twenty-Five Thousand a Minute

1. At a Glance

Issue study · From the public record. Neither organisation named as a case here was an IOanyT client, and IOanyT had no part in the events described. Neither is a retailer: we found no public case of a named retailer whose shop slowed or failed at a peak. Each case is reported as the public record gives it, and the railway, a government body, without judgement.

Organisation type	A large US airline whose long-serving scheduling software met more than it was built for, and a national railway that states the ceiling of its booking system, set beside the position of an online shop before its biggest sale
Size band	The cases: large. Our reader: a mid-size retailer, brand or online seller whose shop slows on its busiest days
Region	The airline: US. The railway: India. The retailer: anywhere
The decision at stake	What to do after a slow sale: buy more servers again, move the hosting, replace the shop, or find the part whose design sets the limit and rebuild it
The public outcome	After a winter storm in 2022, the airline’s crew-scheduling software, about two decades old, could not keep up; thousands of flights were cancelled, losses passed one billion US dollars, and the US transport department fined the airline
Why it matters to a mid-size retailer	A system can work for years with a limit nobody has seen. A shop built for an ordinary day has one part that gives way first, and most firms find out which on the day itself

2. The Business Problem, in the Buyer’s Words

“Every year the sale is our biggest day, and every year the website crawls for the first few hours. Afterwards we are told it was the load, and we buy more servers. Last year we doubled them, and checkout was just as slow. Marketing now sends the sale email in batches to protect the site. I do not know which part of the shop gives way, whether servers were ever the answer, or what I should be spending on before the next sale.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The firm is caught between a shop built for an ordinary day and a sale that is anything but. The answer it can buy quickly, capacity, may not reach the part that limits it.

3. What We Found

Method. We went through the public record on old software that met more than it was built for: reporting on a long-serving scheduling system that could not keep up after a storm, a capacity figure for a national booking system given in a parliamentary answer, two surveys on how firms see their old technology, and the one result of this kind that IOanyT has published, from 2025 and 2026. The retail research behind this study holds no evidence on shops slowing at peak times: no named retailer, no figure for sales lost, no figure for how often it happens.

Software that could not keep up. The first case is a large US airline. This was a storm, not a sale, and an airline, not a shop.

What	Public record
The software	Crew scheduling, about two decades old
What happened	It could not keep up with the changes after a winter storm in 2022
Effect	Thousands of flights cancelled
Cost	Losses of over one billion US dollars
Penalty	A fine from the US transport department

A ceiling, stated. 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, “is about 25,000 tickets per minute”. That is a very large capacity, and it is still a limit, written down in advance. We report the figure as given and say nothing about how the system performs or about its announced replacement.

What firms say about their technology. 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 research behind this study judged the first figure likely to be overstated. In one cross-sector survey of about five hundred US IT professionals, half said the biggest reason they had not upgraded was that the current system still works.

What IOanyT has itself published. In IOanyT’s cloud migration for ITCan, an e-commerce client, capacity went from 300 to 30,000+ concurrent users. 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.

Our reading of why shops give way at peak. These four are our reasoning from the record above. None is a finding of any source.

1. Nobody knows which part gives way first. On an ordinary day, a design that serves fifty people looks the same as one that could serve five thousand.
2. Capacity is fixed. The shop has the same servers on its busiest day as on its quietest, and more cannot be arranged in the hour a rush takes to arrive.
3. One part serves customers one at a time. It was written for a small shop, or written that way to keep stock and payment exact, and no amount of extra capacity changes it.
4. The answer is always more servers. They are what can be bought quickly, so the real limit is not looked for.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Add servers or a bigger hosting plan	The limit really is a shortage of capacity, and the shop’s parts can share the work	Does nothing for a part that serves customers one at a time; the bill rises each year	Right only once the reading shows capacity is the limit
Move the hosting to the cloud	The shop’s parts can run as many copies, and the firm is free to use the cloud	A project with its own risk, not to be made just before a peak; a busy day costs more than a quiet one; does nothing for a part that serves one at a time	Right for the parts that can share the work, as a separate decision
Replace the whole shop	The shop is beyond saving, and the firm can carry a long project	Nobody knows which limit the old shop had, so the new one may repeat the design	We would advise against this as the answer to slow sales alone
Read the code to find the part whose design is the limit, then rebuild that part module by module	Slow sales keep coming back after servers were added	Costs money before anything is faster; removing one limit shows the next	Our recommendation

5. Our Recommendation, and the Decision It Asks of the Board

For the code a retailer built or had built (the stock check, the checkout steps, order handling and the links to the warehouse and the accounts): find the part first, then rebuild it. Read the code to see how each shared part is built and what waits on it, and name the part whose design is most likely to set the limit. Then rebuild that part module by module beside the old shop, with a traceability matrix to prove each module does what the old one did. The old shop keeps trading until each module is accepted. Where the reading shows that the limit is a shortage of capacity and the parts can share the work, a move of hosting may be the right answer instead or as well, as a separate decision. Behaviour at peak volume is measured by a load test the retailer’s own team arranges, and the peak day is run on a plan the retailer’s own team owns.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the retailer’s own figures, taken in the first review.

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	Rebuilt module by module beside the old shop, each module shown to do what the old one did	The traceability matrix
Answers considered after a slow sale	One: more servers	Four, each weighed against the part that gave way	The cost comparison
Behaviour at peak volume	Learned from customers on the day	Measured before the peak in a load test the retailer’s team arranges; IOanyT claims no figure	The retailer’s own load test
A peak-day plan	In one engineer’s head	Written and owned by the retailer’s team	The retailer’s plan; IOanyT takes no part on the day

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the shop, the last sale and the servers bought since. 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 study 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 map of the system as it stands, 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. 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.

8. What the Client Would Own

• The map and the specification: what the shop’s own code does, in writing, with each shared part and what waits on it.
• The risk register: the parts most likely to set the limit, listed before any price is set.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement, with how it was checked.
• The code: the rebuilt modules are the client’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

The load test and the peak-day plan belong to the retailer’s own team.

9. What This Approach Does Not Cover

• IOanyT does not monitor or run the shop, and is not on call on the day of a sale. The retailer’s own team or agency runs it, before, during and after.
• IOanyT does not host the shop.
• IOanyT promises no uptime and no figure for speed or capacity, and claims nothing about how the shop will behave at peak volume.
• IOanyT does not run load tests, and its assessment does not include one. Reading the code shows where limits are likely to be; only a test gives a number. A traceability matrix shows that a rebuilt part does what the old one did, not how it behaves under full load.
• When one limit is removed, the next narrowest part becomes the limit, so the work may not end with one module.
• 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 just before a peak.
• IOanyT does not install, upgrade, move or choose a packaged shop platform or a packaged ERP product, and cannot reach a limit inside a hosted platform or a payment company’s system. It does not secure, scan or monitor a shop.
• IOanyT does not offer a compliance, audit or legal service, and says nothing about what card-payment or data protection rules require of a particular firm.
• This study does not say IOanyT would have prevented the events described. IOanyT’s one published result of this kind was a move of hosting; it has no published case of rebuilding a retailer’s old code.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
Trade press, 2026	The airline: the software, the cancellations, the losses and the fine
News report of a Lok Sabha written answer, 20 August 2025	Indian Railways’ reservation capacity, as the railway minister gave it
News report of a vendor-sponsored survey, March 2025	How mid-size firms see their technology
A vendor’s survey, 2025	Why firms have not upgraded
IOanyT case study	IOanyT’s cloud migration for ITCan

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Every system has a ceiling; we read the code to find which part of a shop sets it, before the next sale does.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →