Understanding the Work

It is easier to recommend an efficiency improvement before you know very much about the workload. The recommendation gets more interesting once you understand why the database needs room to recover, what happens while a stream catches up, or why a data service that looks quiet most of the day suddenly needs a large allocation to rebuild on a deadline.

This part moves from observing consumption to understanding the systems that drive it. It begins with one service and a capacity decision we can follow all the way through, then works through measurement and the providers’ own tools. Most of it goes to workloads that expose different measurement problems. AI adds a new kind of consumption to those systems: expensive, scarce, quickly changing, dependent on behavior, and increasingly tied to how the product itself behaves. The monster has a brain. AI services consume resources through several channels, and orchestration can obscure which task caused the work. GPUs and other specialized hardware have different costs, lead times, and failure domains from the general-purpose fleet, and emerging hardware raises the question of when a research result becomes capacity anyone can plan on. Databases and streaming platforms are sized by data model, retention, and query behavior as much as by machine count. The part closes by asking whether a change was worth making.

The capacity team is often the one asked to compensate for an engineering decision it didn’t make. The detail in these chapters is what lets it recognize the problem while changing the design is still cheaper than compensating for it, and ask the specialists who understand these systems the right questions, without pretending that a central team can master every technology the enterprise depends on.