Every Booking System Has a Ceiling. Most Firms Learn Theirs in the Busiest Week.

It is the Friday before the long holiday weekend. The season’s offer went to every agent on Thursday night.

By nine in the morning the booking screen takes a minute to answer. Agents phone the reservations desk to ask whether their bookings went through. The head of technology is on a call with two engineers, restarting one service after another to see what helps.

At noon they find it. Every search was asking one table in the database which seats were still free, and that table could answer only one question at a time. By then the morning’s bookings have gone elsewhere.

What We Found

For this article we went through the public record on booking and operating systems in travel and transport that met their limits: a published capacity figure for a national booking system, reporting on an airline’s two IT groundings, and one cross-sector survey of how firms see their old systems, all published in 2025.

First, what we did not find: no case of a mid-size logistics, travel or hotel firm whose booking, dispatch or tracking application slowed or failed in its busy season, and no figure for what a slow morning costs one. Every named organisation below is far larger than the firms we write for.

A limit can be known in advance. 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 report the figure as given and use it for one point only: a ceiling can be written down before the day it matters. In most mid-size firms, nobody can write down theirs.

A whole operation can stop when one part it depends on fails. This is a large US airline, and the causes it gave were failures at data centres, not demand. It had two IT groundings “in a matter of months” in 2025, in July and on 23 October. On the October day the airline said, “we’ve had more than 229 flight cancellations”. The cause it gave was “a failure at its primary data centre” (not, it said, a cybersecurity incident); in July it was “a critical hardware failure at a data centre”. This was not a system overwhelmed by bookings, and we do not present it as one. Our point, which is our reading and not a finding about the airline: when one part that everything leans on stops, everything behind it stops too, and in most firms that part is named on the day it fails.

Old systems are widely seen as hard to grow. In one cross-sector survey of 504 IT professionals in the US, which is not about this sector, 40% named limited scalability (the difficulty of growing a system with demand) among the top issues with their old systems.

“It still works” keeps old systems in place. In the same survey, half said the biggest reason they had not upgraded is that the current system still works. In an ordinary week an old booking application does still work, which is why its weakest part stays hidden.

Our reading: an application built for an ordinary week has one part that gives way first under a rush, often the search for free seats, rooms or vehicles, the step that allots them, or the shared database. Nobody knows which, so the firm finds out in the one week it can least afford to.

What Waits on a Limit Nobody Knows

A slow Friday in the season is usually called bad luck. Our reading is that the cost was set months earlier, by not knowing.

The offer is planned blind. Sales asks what the system can take. Nobody can say, so the offer is held back, sent in parts, or sent into the unknown.

The wrong fix is bought. Servers can be bought quickly, so servers are bought. Whether they were the limit, nobody checked.

The lesson is lost. What was found at noon lives in one engineer’s memory, and the next season finds the same part.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Prepare for the Next Season, Weighed

There are four real options. Each one is right for somebody.

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
Move the hosting to the cloud, with capacity that rises and falls	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 a busy week in the cloud costs more than a quiet one
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 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	Slow seasons keep coming back, even after servers were added	It costs money before anything is faster, and removing one limit shows the next

Where You Are Now, and Where You Should Be

Before any work begins we set a benchmark: a few measures taken from your own application, each with a target. For this issue it would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Shared parts of the application (database, availability search, allotment step)	Not listed	Each listed, with the screens and jobs that wait on it	The specification
How each shared part is built	Assumed fine, because the ordinary week is fine	Marked: built to serve many at once, or one after another, as read from the code	The risk register
The part most likely to give way first	Found in the busy week, if at all	Named in a quiet month, with the reason	The risk register
What each limit would need	”More servers”	Matched to more capacity, a change to the code or a rebuild	The cost comparison and 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 figures, 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

1. 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.
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 booking, dispatch or tracking application 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. 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 application. We never do a single cutover. Each module has a traceability matrix. 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 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. Our assessment does not include a load test, and we do not run load tests; only a test gives a number. 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. 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 busiest weeks of the year stop being the weeks the firm fears, because the weak point is known and there is a plan for it.
CTO or CIO	A written list of the parts that serve users one at a time, in the order they would give way, in place of a search made during the rush.
CFO	Money for capacity goes to the part that sets the limit, and is not spread over everything in the hope that it helps.
COO	Dispatch and the front desk know beforehand what a slow system would hold up, and have agreed what they will do by hand.
Head of sales and marketing	Sales knows which part of the booking system a large offer would strain first, and plans the launch with that in view.

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 or scale. For a firm’s own booking application, we read the code to show where its limits are likely to be; we do not measure them.
A large US airline had two IT groundings in a matter of months in 2025; the airline gave failures at data centres as the causes.	Our part is far narrower, and we do not say what would have helped. We do not work on airline systems, data centres or hardware, and we host and run nothing. For an application a firm built, we read the code and write down which parts the rest of it leans on.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We find the part that gives way first in a quiet month, so nobody finds it at noon on the busiest Friday.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →