Four
For about a month I was convinced Trakt could serve more traffic than it did, and I was wrong in a way that took me an embarrassing amount of time to see.
The number was four. Four heavy operations at once, platform wide. Not four per airline. Four total, across every operator on the system, every overnight script hitting our API, every fleet dashboard someone had left open in a browser tab somewhere in the world. The number came out of the hardware, and the hardware had no interest in my roadmap.
So I did what you do. Caching. Query tuning. I moved work between services to see whether the bottleneck moved with it. At one point I got a quote for a substantially larger machine, sat with the figure for a day, and quietly closed the tab, partly because of what it cost and partly because I had a nagging feeling the ratio underneath wouldn't change even if I paid it.
A month. Pushing on the wrong variable the whole time.
Part I: The equation
Little's Law is L = λW. L is how many items are inside a system at once, λ is the rate they move through it, and W is how long each one stays.
Rearrange it and you get λ = L / W.
I want to be honest about how long it took me to actually read that. I had seen it years ago in a queuing theory context and filed it somewhere between academic and obvious. What it says is that throughput is an output. You never set it directly. It falls out of the other two numbers, and if one of those numbers is nailed to the floor by hardware or budget or physics, there is exactly one thing left to move.
Mine was nailed at four.
Part II: Time in system is the whole bill
I stopped guessing and measured how long each piece of work actually sat inside the system.
The worst one held a slot for 23 seconds. A single request. At a ceiling of four, that request was eating a quarter of everything the platform could do and holding onto it for 23 seconds. Four of those arriving in the same window and there was nothing left for anybody. The airline waiting on a fleet health report got nothing. Neither did the AMOS sync running quietly in the background, or the operator whose script calls us at three in the morning because that is when their day closes out.
There is a second cost the arithmetic doesn't capture. People judge software on a fairly savage internal clock. A hundred milliseconds feels instantaneous. A second and they notice. Somewhere past ten they assume it's broken, and around twenty they act on that assumption and hit refresh, which fires the same expensive request while the first one is still grinding away. Now two of my four slots are burning on identical work for one impatient human. Scripts behave worse. A script times out, retries on a schedule, and keeps hammering the exact request that caused the problem in the first place. Slowness generates its own traffic, and the traffic it generates is the heaviest kind you have.
Everything queued behind those slots inherits the wait. A request that finishes in 200ms sits for 20 seconds before its own clock even starts, so the platform feels broken to the people running our fastest operations, none of whom did anything to deserve it.
Run the numbers. Twenty three seconds against a ceiling of four works out to roughly one item every six seconds. Get the same work down to a third of a second and you're moving something like a dozen items per second on identical hardware. Same ceiling, no new machine, getting on for seventy times the capacity.
I had that request filed under user experience. Slow screen, annoying, someday. The equation files it under capacity, and once you see it that way it stops looking like a slow screen and starts looking like a rolling outage that every customer paid for whether or not they ever opened the page.
Part III: This is your maintenance program
Then it stopped being a software story.
Trakt exists to predict aircraft component failures before they happen. ACARS, ADS-B, sensor telemetry, MRO records, pilot reports, technical bulletins, all of it feeding an ensemble that turns the pile into advance warning. That is the product. And somewhere in the middle of staring at λ = L / W for my own infrastructure, it landed on me that I had been looking at the same equation inside our customers' operations for years without once calling it by name.
Let L be the aircraft in maintenance at any given moment. Let W be turnaround. λ becomes the rate you cycle airframes back into revenue service.
Every operator on earth wants a bigger λ, because a bigger λ means more revenue hours per tail. Almost everyone goes after it through L: another bay, more hangar space, more technicians on the floor, a capital expenditure request that has to travel up several levels before anybody signs it.
That does work. It is also the most expensive answer available to you.
The cheap answer is W. Compress time in system and throughput rises without a new bay, a new building, a new hire, or a new raise, because the shortage was never capacity. It was time.
Hold a maintenance slot for six days when it could have been three, and the real cost is every other aircraft that could have cycled through while it sat there occupied.
Which is the same sentence as my 23 seconds. It took me years to notice because one version was written in Python and the other in aluminum.
Part IV: The objection
I know the pushback. Aircraft aren't HTTP requests. There are regulatory sign offs, parts lead times, certification requirements, and human beings who are legally required to rest.
All of that is true, and none of it touches the equation. Little's Law holds for queues at a bank, cars on a highway, patients in an emergency department, and aircraft in a hangar. It is arithmetic, and arithmetic doesn't become optional because your queue has a tail number.
What the constraints change is which parts of W you are allowed to attack. The lever itself stays where it is.
The uncomfortable bit is what W is made of, because most of W is waiting. A part sitting in transit. A decision nobody was actually asked to make. An aircraft that came ready on Thursday afternoon and went unnoticed until Friday. A task booked for Tuesday when today is Monday and the bay is empty.
When I finally profiled my 23 second monster, it turned out to be a fleet health endpoint pulling every sensor reading we had ever stored, for every component, on every aircraft in the fleet, most of it years old and superseded several times over, in order to render a screen that displayed about forty numbers. Almost none of that duration was computation. The system was reading data it had no business reading while everything else sat behind it doing nothing at all, which is idle time in a busy costume.
I would bet money the same holds in most hangars. The gaps between wrench time are where the days go, and nobody measures the gaps, because nobody sends you an invoice for them.
Part V: What prediction is actually selling
This is the part where I think my own industry undersells itself, and I include the earlier version of me who pitched it this way.
The standard predictive maintenance pitch is failure avoidance. Catch the component before it goes, dodge the AOG event, avoid the disruption cost that follows. All true, all easy to fit on a slide. It also frames the whole product as insurance against a bad day.
Little's Law makes a much larger claim on its behalf.
Trakt gives operators somewhere between 2 and 13 weeks of advance warning on at risk components. Sit with what that window does to W. The part is on the shelf before the aircraft is in the bay. The task gets bundled into work already on the schedule. The slot gets booked when it suits the operation rather than when a failure forces the timing.
Read through the equation, that advance warning is doing something structural. It compresses W, and a compressed W lifts λ across the entire fleet, permanently, without a single yard of new hangar concrete.
Underneath the packaging, what prediction sells is the removal of waiting.
What I actually believe
I lost a month hunting for a bigger number when I should have been hunting for a shorter one.
Almost everyone makes that trade, and I don't think it's stupidity. It's the natural instinct, and it happens to be exactly what capital markets are built to accommodate. Throughput feels like something you ought to be able to buy, so people buy it. More workers, more bays, a bigger machine, another building.
The equation disagrees. When L is expensive to move, and it nearly always is, W is the whole game.
My ceiling is still four. I never raised it. Every gain Trakt made this year came out of W, and there is more sitting there, because there is always more waiting to remove than you would guess.
Somewhere right now an operator is signing off on new hangar capacity to fix what is really six days of parts sitting on a truck.
Same equation, considerably larger invoice.
Stop trying to raise λ. Go find your W.
