The Six Pressures: Reading a Design Under Stress

Why this matters

A design that has never been pushed is a drawing. You learn almost nothing from looking at one, because on a whiteboard everything works: the boxes are the right size, the network never drops packets, and the third-party API always answers. The only way to find out whether a design is understood is to apply pressure and watch which joint moves first. This course applies exactly six pressures, the same six, to every system it builds — not because six is a magic number but because these six are close to orthogonal. Each one loads a different structural axis, and a design can pass any five and fail the sixth badly. Once you have run a design through all six a dozen times, the questions stop being an exercise and become a reading habit: you start seeing where a design will bend before anyone asks you to push it, which is the entire skill this course is trying to install.

Demo

Here are the six, what each one is really probing, and what usually breaks first when you apply it to a typical read-heavy web system.

1. Traffic becomes 100x. Axis: throughput and capacity. First casualty: usually not the thing people name. It is rarely CPU; it is connection limits, a single write primary, or a queue that grows without bound because the consumer never got scaled with the producer.

2. One region goes down. Axis: availability and failure domains. First casualty: whatever quietly had exactly one copy — a primary database, a coordination service, a config store, or a DNS record with a long TTL.

3. Duplicates become unacceptable. Axis: correctness under retry. First casualty: any write path where the client retries and the server has no idempotency key. Networks retry silently; at-least-once is the default of the universe and exactly-once is something you build.

4. Reads must be under 100 ms. Axis: tail latency. First casualty: the fan-out. If one request touches ten services in sequence, your p99 is not the p99 of any one of them — it is much worse, because you need all ten to be fast simultaneously.

5. Data must stay in country. Axis: topology under regulation. First casualty: the global cache, the analytics pipeline, the backup bucket, and every third-party vendor you forgot processes your data too.

6. A critical dependency became unreliable. Axis: blast radius and isolation. First casualty: your own availability, via a thread pool that fills with requests waiting on a timeout that was set to 30 seconds by a default nobody chose.

Every stress task in this course answers the same six questions in the same order, so the shape becomes automatic: Scale — the concrete number that changed. Bottleneck — what breaks first, and why it rather than something else. Decision — the one thing you actually change. Tradeoff — what that decision costs, because there is always a cost. Incident — a plausible concrete failure this prevents or causes. Outcome — the measurable state afterwards.

And then, always, the paragraph that matters most: what does NOT change, and why. That is task six.

Try it yourself

1. Take the checklist and fill the three missing blocks (sub-100 ms reads, data residency, flaky dependency) for the photo app from the estimation task. Each bottleneck line must name one specific component, not an area.
2. Find a pressure that is genuinely not covered by these six and argue for it in two sentences. Most candidates collapse into one of the six on inspection — if yours does not, you have found a seventh axis worth knowing.
3. Apply pressure 6 to a system you use: pick its most important third-party dependency, assume a 5 percent error rate and a 10 second latency, and write what the user sees. Then write what they should see instead.
4. For each of the six, write down which one your current or most recent project would fail worst. Rank them, then check the ranking against your actual incident history — mismatches are where your intuition is miscalibrated.
5. Rewrite any one block so that the decision line is deliberately wrong, then follow the tradeoff and incident lines to their conclusion. Being able to narrate a bad decision to its failure is how you learn to reject one quickly.

References

• Google SRE Book — Addressing cascading failures
• AWS Builders Library — Timeouts, retries and backoff with jitter
• Cloudflare postmortems
• Designing Data-Intensive Applications (Kleppmann)