A component's capacity ceiling is best expressed in the terms users feel, not in raw system counters. At Flickr, photo servers serve tens of thousands of images per second, but the maximum is **not** defined by disk I/O, CPU, or memory — it's defined as how many images a server can serve before the *time to serve* each image exceeds a specified threshold. The system metrics still matter for diagnosis, but the *red line* is the user-facing service-level target. This guards against the trap where every infrastructure gauge looks healthy while latency has already crossed into unacceptable — common with static content, where you hit a latency wall before CPU/disk/memory complain. Set the ceiling at the experience boundary, then map which resource you'll exhaust on the way there. --- *Source: [[The Art of Capacity Planning]] (John Allspaw, O'Reilly 2008) — Ch 2 — Setting Goals for Capacity*