Four.
That was the ceiling I ran into while building Trakt System at Kquika. Four heavy operations at once. Across every airline on the platform, every operator's overnight script calling our API, every fleet dashboard anyone had open anywhere in the world. Four. The number came from physical reality, and physical reality had no interest in my roadmap. I spent a month trying to lift how much the platform could serve. Caching, query tuning, shuffling work between services, and at one point pricing out a much bigger machine before admitting the quote was enormous and the math underneath it wouldn't change. A month of my life, gone.
The entire time, I was pushing on the wrong variable.
Part I: The Equation
Little's Law. L = λW.
L is how many items sit inside a system at once. λ is the rate they flow through it. W is how long each one stays.
Rearranged: λ = L / W.
Read it slowly, because it took me a month to actually read it. Throughput falls out of the other two numbers. You never set it directly, and when L is pinned down by hardware, budget, or physics, exactly one lever remains. Mine was pinned at four. Every gain I wanted had to come out of W. I had spent a month optimizing an output.
Part II: Time in System Is the Whole Bill
So I stopped guessing and measured the only thing that mattered: how long each piece of work occupied the system. The worst offender held a slot for 23 seconds. One request. At a ceiling of four, that single request swallowed a quarter of everything Trakt could do, and held it for 23 seconds. Four of those landing together and the platform had nothing left. The airline waiting on a fleet health report got nothing. Neither did the AMOS sync running in the background, or the operator whose script calls us programmatically at three in the morning because that is when their day closes out.
And 23 seconds carries a second cost the math doesn't show. People judge software on a savage clock. Around 100 milliseconds feels instant. Around one second, they notice. Past ten, they assume something broke. By twenty, they act on that assumption and refresh the page, which fires the same heavy request again while the original is still grinding, so now two of my four slots are burning on identical work for one person. An overnight script behaves even worse. It times out, retries automatically, and keeps retrying on a schedule, hammering the exact request that caused the problem in the first place. Slowness manufactures its own traffic, and the traffic it manufactures is the heaviest kind.
Meanwhile everything queued behind those slots inherits the delay. A request that should finish in 200 milliseconds now waits 20 seconds for a slot before its own clock even starts, so the platform feels broken to the people running our fastest operations, none of whom did anything to cause it.
The arithmetic is brutal. Twenty three seconds against a ceiling of four works out to roughly one item every six seconds. Bring that same work down to a third of a second and the platform moves about a dozen items every second, with the same ceiling, zero new hardware, and nearly seventy times the capacity. I had been treating that request as a slow screen problem. In truth it was an outage running on a timer, and every customer on the platform paid for it whether they ever touched that screen or not.
That reframe is the most valuable thing I learned all year. I had filed latency under user experience. The equation files it under capacity.
Part III: This Is Your Maintenance Program
Then it stopped being a software story. Trakt exists to predict aircraft component failures before they happen. We pull in ACARS, ADS-B, sensor telemetry, MRO records, pilot reports, and technical bulletins, and an ensemble of models turns all of it into advance warning. That is the product. And while I was staring at λ = L / W for my own infrastructure, it hit me that I had been looking at the exact same equation inside my customers' operations for years without ever naming it.
Set L to the aircraft sitting in maintenance at any given moment. Set W to turnaround time. λ becomes the rate you cycle aircraft back into revenue service. Every operator on earth wants a higher λ, because a higher λ means more revenue hours per airframe. And almost everyone reaches for L to get it. More bays, more hangar space, more technicians, more capital expenditure.
That works. It's also the most expensive answer on the table.
The cheap answer is W. Compress time in system and throughput rises with no new bay, no new building, no new headcount, and no new capital raise, because capacity was never your shortage. Time was.
A maintenance slot held for six days instead of three costs you far more than three days. It costs you every aircraft that could have cycled through that slot while it sat occupied.
That is the same sentence as my 23 seconds. I failed to recognize it for years because one version was written in software and the other in aluminum.
Part IV: The Objection
I know the argument before anyone makes it. Aircraft aren't HTTP requests. Maintenance carries regulatory sign offs, parts lead times, certification requirements, and human beings who are legally required to rest.
All true. 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. This is arithmetic, and arithmetic doesn't become optional because your queue has a tail number.
What the constraints change is which part of W you can attack. The lever stays the same.
The uncomfortable part is what W is actually made of. Most of W is waiting.
Waiting on a part stuck in transit. Waiting on a decision nobody was asked to make. Waiting because the aircraft was ready and no one noticed. Waiting because the task was booked for Tuesday and today is Monday.
When I finally profiled my own 23 second monster, the culprit was a fleet health endpoint that pulled every sensor reading we had ever stored for every component on every aircraft in the fleet, most of it years old and long superseded, in order to render a screen that displayed about forty numbers. Almost none of that duration was computation. It was the system reading data it had no business reading, while other work sat behind it doing nothing at all. Idle time wearing a busy costume.
I would wager real money the same is true in most hangars. Wrench time is rarely your problem. The gaps between wrench time are your problem, and nobody measures the gaps because nobody gets invoiced for them directly.
Part V: What Prediction Is Actually Selling
This is where I think my own industry undersells itself, and I include the earlier version of me that pitched it this way. The standard pitch for predictive maintenance is failure avoidance. Catch the component before it fails. Dodge the AOG event and the cost of the disruption that comes with it. All of it true, and all of it easy to fit on a slide.
That pitch frames prediction as insurance against a bad day.
Little's Law says something far bigger. Trakt gives operators 2 to 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 enters the bay, and the task gets bundled into work already on the schedule. The slot gets booked when it suits the operation instead of when a failure forces the issue.
Seen through the equation, that advance warning does something bigger than preventing a failure. It compresses W. And compressed W lifts λ across the entire fleet, permanently, without pouring a single yard of new hangar concrete.
Prediction, at its core, sells the removal of waiting. Everything else is packaging🤷♂️.
What I Actually Believe
I lost a month because I went hunting for a bigger number when I should have been hunting for a shorter one.
Everybody makes this trade. It's the natural instinct, and it's exactly what capital markets are built to indulge. Throughput feels like something you should be able to buy, so people buy it. More workers, more bays, more machines, more spend.
The equation disagrees. When L is expensive to change, and it almost always is, W is the entire game.
My ceiling is still four. I never raised it. Every gain Trakt made this year came out of W, and there is more on the table, because there is always more waiting to remove than you think.
Somewhere right now an operator is signing off on new hangar capacity to solve what is actually six days of parts sitting in transit.
Same equation. Same mistake. Considerably larger invoice.
Stop trying to raise λ. Go find your W.
That was the ceiling I ran into while building Trakt System at Kquika. Four heavy operations at once. Across every airline on the platform, every operator's overnight script calling our API, every fleet dashboard anyone had open anywhere in the world. Four. The number came from physical reality, and physical reality had no interest in my roadmap. I spent a month trying to lift how much the platform could serve. Caching, query tuning, shuffling work between services, and at one point pricing out a much bigger machine before admitting the quote was enormous and the math underneath it wouldn't change. A month of my life, gone.
The entire time, I was pushing on the wrong variable.
Part I: The Equation
Little's Law. L = λW.
L is how many items sit inside a system at once. λ is the rate they flow through it. W is how long each one stays.
Rearranged: λ = L / W.
Read it slowly, because it took me a month to actually read it. Throughput falls out of the other two numbers. You never set it directly, and when L is pinned down by hardware, budget, or physics, exactly one lever remains. Mine was pinned at four. Every gain I wanted had to come out of W. I had spent a month optimizing an output.
Part II: Time in System Is the Whole Bill
So I stopped guessing and measured the only thing that mattered: how long each piece of work occupied the system. The worst offender held a slot for 23 seconds. One request. At a ceiling of four, that single request swallowed a quarter of everything Trakt could do, and held it for 23 seconds. Four of those landing together and the platform had nothing left. The airline waiting on a fleet health report got nothing. Neither did the AMOS sync running in the background, or the operator whose script calls us programmatically at three in the morning because that is when their day closes out.
And 23 seconds carries a second cost the math doesn't show. People judge software on a savage clock. Around 100 milliseconds feels instant. Around one second, they notice. Past ten, they assume something broke. By twenty, they act on that assumption and refresh the page, which fires the same heavy request again while the original is still grinding, so now two of my four slots are burning on identical work for one person. An overnight script behaves even worse. It times out, retries automatically, and keeps retrying on a schedule, hammering the exact request that caused the problem in the first place. Slowness manufactures its own traffic, and the traffic it manufactures is the heaviest kind.
Meanwhile everything queued behind those slots inherits the delay. A request that should finish in 200 milliseconds now waits 20 seconds for a slot before its own clock even starts, so the platform feels broken to the people running our fastest operations, none of whom did anything to cause it.
The arithmetic is brutal. Twenty three seconds against a ceiling of four works out to roughly one item every six seconds. Bring that same work down to a third of a second and the platform moves about a dozen items every second, with the same ceiling, zero new hardware, and nearly seventy times the capacity. I had been treating that request as a slow screen problem. In truth it was an outage running on a timer, and every customer on the platform paid for it whether they ever touched that screen or not.
That reframe is the most valuable thing I learned all year. I had filed latency under user experience. The equation files it under capacity.
Part III: This Is Your Maintenance Program
Then it stopped being a software story. Trakt exists to predict aircraft component failures before they happen. We pull in ACARS, ADS-B, sensor telemetry, MRO records, pilot reports, and technical bulletins, and an ensemble of models turns all of it into advance warning. That is the product. And while I was staring at λ = L / W for my own infrastructure, it hit me that I had been looking at the exact same equation inside my customers' operations for years without ever naming it.
Set L to the aircraft sitting in maintenance at any given moment. Set W to turnaround time. λ becomes the rate you cycle aircraft back into revenue service. Every operator on earth wants a higher λ, because a higher λ means more revenue hours per airframe. And almost everyone reaches for L to get it. More bays, more hangar space, more technicians, more capital expenditure.
That works. It's also the most expensive answer on the table.
The cheap answer is W. Compress time in system and throughput rises with no new bay, no new building, no new headcount, and no new capital raise, because capacity was never your shortage. Time was.
A maintenance slot held for six days instead of three costs you far more than three days. It costs you every aircraft that could have cycled through that slot while it sat occupied.
That is the same sentence as my 23 seconds. I failed to recognize it for years because one version was written in software and the other in aluminum.
Part IV: The Objection
I know the argument before anyone makes it. Aircraft aren't HTTP requests. Maintenance carries regulatory sign offs, parts lead times, certification requirements, and human beings who are legally required to rest.
All true. 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. This is arithmetic, and arithmetic doesn't become optional because your queue has a tail number.
What the constraints change is which part of W you can attack. The lever stays the same.
The uncomfortable part is what W is actually made of. Most of W is waiting.
Waiting on a part stuck in transit. Waiting on a decision nobody was asked to make. Waiting because the aircraft was ready and no one noticed. Waiting because the task was booked for Tuesday and today is Monday.
When I finally profiled my own 23 second monster, the culprit was a fleet health endpoint that pulled every sensor reading we had ever stored for every component on every aircraft in the fleet, most of it years old and long superseded, in order to render a screen that displayed about forty numbers. Almost none of that duration was computation. It was the system reading data it had no business reading, while other work sat behind it doing nothing at all. Idle time wearing a busy costume.
I would wager real money the same is true in most hangars. Wrench time is rarely your problem. The gaps between wrench time are your problem, and nobody measures the gaps because nobody gets invoiced for them directly.
Part V: What Prediction Is Actually Selling
This is where I think my own industry undersells itself, and I include the earlier version of me that pitched it this way. The standard pitch for predictive maintenance is failure avoidance. Catch the component before it fails. Dodge the AOG event and the cost of the disruption that comes with it. All of it true, and all of it easy to fit on a slide.
That pitch frames prediction as insurance against a bad day.
Little's Law says something far bigger. Trakt gives operators 2 to 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 enters the bay, and the task gets bundled into work already on the schedule. The slot gets booked when it suits the operation instead of when a failure forces the issue.
Seen through the equation, that advance warning does something bigger than preventing a failure. It compresses W. And compressed W lifts λ across the entire fleet, permanently, without pouring a single yard of new hangar concrete.
Prediction, at its core, sells the removal of waiting. Everything else is packaging🤷♂️.
What I Actually Believe
I lost a month because I went hunting for a bigger number when I should have been hunting for a shorter one.
Everybody makes this trade. It's the natural instinct, and it's exactly what capital markets are built to indulge. Throughput feels like something you should be able to buy, so people buy it. More workers, more bays, more machines, more spend.
The equation disagrees. When L is expensive to change, and it almost always is, W is the entire game.
My ceiling is still four. I never raised it. Every gain Trakt made this year came out of W, and there is more on the table, because there is always more waiting to remove than you think.
Somewhere right now an operator is signing off on new hangar capacity to solve what is actually six days of parts sitting in transit.
Same equation. Same mistake. Considerably larger invoice.
Stop trying to raise λ. Go find your W.
Related Posts
