Where Distributed Systems Actually Waste Infrastructure Spend

Start with usage, not architecture. Pull request volume and resource utilization per service, and look for anything running at low traffic but provisioned like it still matters. A service built for a feature that shipped and never took off is a common source of quiet, ongoing spend.

Say your team is paying for a dedicated cluster that handles a feature used by 2 percent of customers. Consolidating it onto shared infrastructure, or retiring it outright, usually saves more than any tuning you could do to the service itself.

The hard part is rarely finding these services, it's getting agreement to shut them down. Nobody wants to be the one who breaks a feature they thought was already dead, so give each candidate a two-week window with monitoring on its traffic before anyone actually flips it off.

Teams often buy a cost-management platform before checking whether their existing instances are even sized correctly. Pull CPU and memory utilization over a 30-day window for your ten most expensive services. Say one of them is sitting well below a third of its provisioned capacity every day of that window: that's a candidate for a smaller instance class or autoscaling instead of a fixed, oversized footprint.

This step alone, done by hand with a spreadsheet, often closes more of the gap than the tooling purchase that usually comes next.

Autoscaling deserves a second look too, not just instance size. A fleet that scales up fast but scales down slowly, because someone set a conservative cooldown period during an incident and never revisited it, quietly pays for peak-sized capacity most of the day.

For anything that recurs, logging, monitoring, message queues, the build-versus-buy math usually favors buying until you're at a scale where the managed service's margin genuinely exceeds what an engineer's time costs to run it yourself.

A useful rule: if a managed version of something costs less per month than one engineer's fully loaded time to operate the self-hosted version, buy it, and revisit that math once volume changes by an order of magnitude, not every quarter.

The exception is anything core to what makes your product different. A message queue is rarely that; the specific way you route and prioritize work through it sometimes is. Spend the build effort on the second kind of problem, not the first.

• Cost dashboards nobody checks because they're not tied to a team's own budget
• Reserved capacity bought for peak load that sits unused most of the month
• Data transfer costs between services in different regions that nobody accounted for at design time
• A cost-cutting sprint that saves money for one quarter and then drifts back as new services launch

The drift is the real problem. A single cleanup pass without a recurring review just delays the next spike.

Put a standing 30-minute review on the calendar each month where each team looks at its own infrastructure spend against its own usage. Teams that own their number tend to catch drift early; teams where cost is someone else's problem tend to find it a quarter later, after it's already expensive to unwind.

Say a mid-size distributed system is running $40,000 a month in infrastructure spend. A first-pass review usually turns up the same three things: a staging environment sized like production, a logging pipeline retaining far more data than compliance or debugging actually requires, and two or three services still running from a feature that got deprioritized.

Rightsizing staging and trimming log retention alone often closes a meaningful chunk of that bill without touching production performance at all. The deprioritized services take longer, since someone has to confirm nothing quietly depends on them, but they're usually worth the hour it takes to check.