"Queries per second" is a poor capacity metric because query costs vary by 1,000x or more. A software update can change the ratio overnight. Google measures capacity in actual resources (CPU cores, memory) and models per-request cost as normalized CPU time across architectures. ## Why CPU Works as the Primary Signal - Memory pressure translates to increased CPU via garbage collection - Other resources can usually be over-provisioned cheaply relative to CPU - When over-provisioning non-CPU resources is too expensive, track each resource separately ## Per-Customer Quotas in CPU-Seconds Google sets customer quotas in CPU-seconds per second (not QPS): - Gmail: 4,000 CPU-sec/sec - Calendar: 4,000 CPU-sec/sec - Android: 3,000 CPU-sec/sec Quotas can sum to more than total capacity (oversubscription) — relying on customers not peaking simultaneously. ## The Anti-Pattern Any capacity model based on "queries per second" or static request features (e.g., "number of keys read") creates a moving target. When the proxy metric drifts from actual resource consumption, load balancing and capacity planning silently degrade. --- *Source: [[SRE Book Ch 21 - Handling Overload]] — Site Reliability Engineering (Google, O'Reilly 2016) — Ch 21 — Handling Overload*