Most teams read a rising infrastructure bill as a growth chart. Traffic went up, customers went up, so the invoice went up, and someone approves it.
Sometimes that reading is right. The bill does contain demand, and demand is the part worth paying for. It also contains other things, and the invoice does not label them.
Take a bill that rises by a fifth in a quarter while usage rises by a twentieth. Someone has to explain the gap, and the usual answer is that growth is expensive. That answer closes the conversation before anyone has looked at the workload.
Three kinds of cost on one invoice
Inside a bill like that, three kinds of cost sit together.
- Demand is work the business asked for: a customer request, a transaction, a job that produced revenue.
- Waste is work the workload never needed.
- Operating effort is hours of people's time spent keeping the system running, which no invoice carries.
Waste takes familiar forms. A query reads a whole table to return ten rows. Logs get written at a volume nobody reads. A service is provisioned for a peak that arrives twice a year. A runtime burns far more CPU and memory than the task calls for. Each of these shows up on the invoice as compute, storage or network, and none of them shows up as a line called waste.
Why more capacity hides the cause
When latency climbs, the reflex is to add capacity. It is quick, and it usually works for a while.
It also locks the inefficiency in, because the larger system now runs the same inefficient behavior at larger scale and the symptom goes away. The bill grows, the graph looks like success, and nobody revisits the cause.
We work across hardware, networking, operating systems and application code, and that range keeps showing us the same thing: a slow service looks like a server problem, and sometimes the cause sits in the code that runs on it.
We rewrote a production service from Python to Rust, which cut latency and resource consumption by roughly 10x and saved approximately $1 million a year. That result belongs to that workload and predicts nothing about yours. It shows that a bill can hold work the workload never needed, and that is the only claim we take from it.
Give spare capacity its due
Waste has a mirror image that deserves its full weight. Some spare capacity protects the business at peak load, and cutting it in the name of savings can leave an engineering team answering for an outage.
A lower bill earns no credit if latency, error rates or the team's own workload got worse to produce it. Our rule is to optimize before scaling and to measure success by business impact.
Split the last increase before approving the next
Before you approve more capacity, split the last increase into three parts.
- Demand: write down what grew and by how much: requests, transactions, jobs, customers.
- Waste: list what ran that the workload did not need, and mark which spare capacity exists to protect reliability.
- Operating effort: count the engineering hours the increase added or removed.
Some of those answers will be missing. A missing answer is a finding too, because it tells you the bill has been explained by habit.
Capacity may still be the right call. Once the split exists, you can approve it with a reason, and finance and engineering can read the same record: the problem, the intervention considered, the evidence and the trade-off.
Its first line is a question that comes before any purchase order. What does the workload need?
If you can trace part of your last infrastructure increase to demand and part of it to nothing at all, tell us which part you could not explain. That is usually where an investigation starts.