The Weeks That Earn the Year. More Servers Are One Answer of Four.
A booking or tracking application sized for an ordinary week meets the season with the same capacity. Here is what that costs, the four ways to answer it (more servers, a hosting move, a packaged product, or a rebuild of the part that is the limit), weighed, and our recommendation.
The tracking portal runs on three servers in a rack at head office. It has run on three servers for seven years.
In an ordinary week they sit mostly idle. In the fortnight before the festival, consignments climb, every customer checks a consignment several times a day, and by mid-morning the portal is timing out. Last year a fourth server was borrowed for the month. It was set up in a hurry, behaved a little differently from the others, and went back in January.
This year sales has signed two large shippers. The supplier says new servers will take five weeks to arrive. Nobody can say whether more servers were the answer last time.
The paradox: The firm has more capacity than it needs for most of the year, and nowhere near enough for the few weeks that earn it.
What We Found
We looked at the public record on systems meeting their limits and on how firms see their old systems, and at the one result of this kind IOanyT has published. It holds no case of a mid-size logistics, travel or hotel firm whose application slowed in its busy season; the outside facts below are labelled so.
We have given one online shop room to grow, by moving its hosting. In IOanyT’s own published cloud migration for an e-commerce client outside this sector, capacity went from 300 to 30,000+ concurrent users (people using the system 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 a logistics, travel or hotel firm.
A ceiling can be stated, even for a very large system. This is a national 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, “is about 25,000 tickets per minute”. We use the figure only to show that a limit can be known in advance. In most mid-size firms, nobody knows theirs.
Firms see their old systems as hard to grow, and keep them anyway. In one cross-sector survey of 504 IT professionals in the US, which is not about this sector, 40% named limited scalability among the top issues with their old systems, and half said the biggest reason they had not upgraded is that the current system still works.
What our review does not show: We found no named firm in this sector of our readers’ size whose application slowed in a busy week, no figure for what a slow week costs, and nothing from the Middle East on this issue. Our own result is one hosting move for one online shop; it says nothing about a booking or dispatch application, or about rebuilding old code. The railway figure is a published capacity. The survey is cross-sector, from a firm that sells related services. That old applications are usually limited by one part, and that more servers often do not reach it, is our reasoning.
The Weeks That Earn the Year
A slow season is usually treated as a technology problem. Our reading is that it is first a business problem: in this sector a few weeks carry the year.
The busiest weeks are the riskiest. A holiday, a festival or a large shipper’s launch brings many times the usual volume in a few days, and the application meets it with the capacity of an ordinary week.
Capacity is bought blind. Fixed servers give the same capacity in the busiest fortnight as in the quietest week. Size them for the peak and pay all year; size them for the average and turn bookings away in the weeks that earn the most.
The offer is shaped by the system. When nobody knows what the booking system can take, the offer goes to agents in parts, and the last group hears about it from the first.
The wrong part gets the money. If the part that gave way serves one request at a time, more servers do not reach it, and the queue stays where it was.
The gap we see: most firms in this sector answer a slow season with one lever, servers, because servers can be bought quickly. The opportunity is to know, before the next season, whether the application is short of capacity or held back by one part’s design, and to spend on that.
This is our reading of the evidence. It is not a measured market figure, and we do not put a value on a busy week here. That figure has to come from your own business.
Four Ways to Answer a Busy Season, 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 application’s parts can share the work | It does nothing for a part that serves users one at a time, and servers bought for the peak sit idle all year |
| Move the hosting to the cloud, with capacity that rises and falls with demand | The application’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 busy season. A busy week in the cloud costs more than a quiet one. It does nothing for a part that serves users one at a time |
| Replace the application with a packaged reservation or booking product | The firm’s way of working fits such a product, and it can carry a long change | The firm’s own rules and links to agents, depots and billing must be refitted to the product. This is the firm’s decision, and not our kind of work |
| Read the code to find the part whose design is the limit, then rebuild that part module by module | Slow seasons keep coming back, even after servers were added | It costs money before anything is faster, and removing one limit shows the next |
Our recommendation: find the part first, then rebuild it. Read the code and name the part whose design is most likely to be the limit. Then rebuild that part, module by module, beside the old application. Where 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: a separate decision, with its own price, and the kind of work behind our one published result. We do not monitor or run your application, we do not host it, and we promise no uptime or capacity. Reading the code is not a load test: it shows where limits are likely, not the number of bookings at which the application fails.
The honest costs. Cloud capacity is paid for by use, so a very busy week costs more than a quiet one. A hosting move should not be made in the weeks before a season. 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 season is planned, we would set a benchmark for the decision.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| Answers weighed after a bad season | One: more servers | Four, each weighed against the part that gave way | The cost comparison |
| The limit behind the last slow week | Called “the load” | Named: a shortage of capacity, or a part built to serve one request at a time, as read from the code | The risk register |
| The cost of a busy week | The hosting bill alone | Servers, staff time, offers held back and the cost of a busy week in the cloud, in one place | The cost comparison |
| The size of one commitment | A new system 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 agents and staff on the day | Measured before the season 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 logistics, travel or hospitality firm.
How We Work With You
- We listen: a free Reliability Review. A first conversation about the application and the last season. 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.
- 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.
- We read the system and propose: the Legacy System Specification Assessment. Here the system is the booking, dispatch or tracking application 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.
- 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 application. 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.
- 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 weeks; someone from operations and finance to say what must never go wrong, such as a seat, room or vehicle allotted twice; and your own team or supplier to run the application before, during and after every season.
What we do not do: we do not monitor or run your application, we do not host it, and we are not on call in a busy week. We promise no uptime, no speed and no capacity. We do not run load tests, and our assessment does not include one. We do not work inside a packaged reservation, booking, warehouse or property management product, whose capacity is its maker’s matter, and we do not install, upgrade, move or choose such products. We do not work on the systems that run aircraft, trains or vehicles. Our published cloud result was a move of hosting for one e-commerce client; we have no published case of this work for a logistics, travel or hospitality firm.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | The weeks that earn the year are planned around a known limit and a chosen answer, not around last season’s guess. |
| CTO or CIO | A choice between more servers, a hosting move, a packaged product and a rebuild of one part, made on evidence and not during the rush. |
| CFO | Money for the busy season goes to the answer that fits the limit, with the cost of each answer set side by side before anything is bought. |
| COO | Operations knows which answer was chosen for the next season, and what it changes for depots, dispatch and the front desk. |
| Head of sales and marketing | The season’s offer is planned around a booking system whose weak point is known and being dealt with, not staggered out of fear. |
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 firm’s own booking or dispatch 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 orders servers for the season, we would find out whether servers were ever the limit.
Sources
In this issue
Systems fail under load
Research note 1
Every Booking System Has a Ceiling. Most Firms Learn Theirs in the Busiest Week.
The public record on booking and operating systems meeting their limits: what we found, why the weak part stays hidden, the options, and our benchmark.
Research note 3
The Day the Plan Changes Is the Day That Counts. Here Is the Benchmark We Would Set.
Servers were doubled and the dispatch screen still froze when a road closed. The benchmark we would set for an old dispatch system before the next bad day.
Issue study
Could Not Keep Up With the Changes
An issue study from the public record: an airline's scheduling software after a storm, two IT groundings, a railway's booking ceiling, options, our benchmark.