The instinct when facing scale is to multiply: if one server handles a thousand requests, ten servers handle ten thousand. If one process takes a second, parallel processes finish in a fraction. This multiplication instinct works—up to a point. Beyond that point, it creates more problems than it solves.
The zoom-out principle. Instead of asking "how do I make this faster for one request?" ask "how does this look when a million requests arrive simultaneously?" The answer changes everything. When you zoom out, you see that the bottleneck is rarely the processing time of a single request. It is the shared resources: the database connection pool, the cache eviction policy, the lock contention on a hot row, the network round trip that every request makes independently.
Designing from the zoomed-out perspective means building systems where the unit of data is not a single record but a batch. Where the unit of computation is not a single request but a pipeline stage. Where data is transmitted as unified entities rather than multiples of individual items.
Concrete example. Consider a system that processes order confirmations. The naive approach sends one email per confirmation. At scale, this means thousands of SMTP connections, each with its own TLS handshake and delivery retry cycle. The zoomed-out approach batches confirmations, sends them through a persistent connection pool, and handles failures at the batch level rather than the individual message level.
Why this matters for procurement. Government systems do not have the luxury of gradual scaling. A procurement portal published on TED may go from zero to peak traffic in a single day when a tender deadline approaches. A benefits system launched through a SAM.gov contract must handle enrollment spikes without degradation. Systems designed with the multiplication mindset—scale by adding instances—fail at these transition points because the shared resources (databases, external APIs, storage) do not multiply as easily.
The zoom-out perspective produces systems that are inherently more efficient, because they were designed for the population, not the individual. And in practice, systems designed for the population handle individual requests faster too—because they have already optimized away the overhead that the multiplication approach would replicate.