The Tradeoffs You Are Already Making

1Seven properties, one system

Andrew Ng lists them almost in passing: latency, availability, consistency, reliability, maintainability, simplicity and cost. They are not a checklist. They are seven forces pulling in different directions, and every line of infrastructure you add moves several of them at once.

Here is the uncomfortable part. None of these properties is a thing you can simply have more of. Each one is bought with something else, and usually the currency is one of the other six.

The instrument below is the course in miniature. Five ordinary decisions, seven meters. Move anything and watch what else moves. There is no configuration where all seven read green, and looking for one is the specific mistake this chapter exists to prevent.

Notice what happens when you pick the strongest option in every row. Reliability and availability go up, and simplicity collapses. You have built something that survives almost anything, that nobody on a four-person team can hold in their head, and that costs more than the revenue of the catalogue it serves. That configuration is not wrong in the abstract. It is wrong for this scenario, and knowing which is the skill.

2What the agent optimises when you do not say

A coding agent is not neutral. Asked for a feature with no constraints attached, it produces the shape that dominates its training data: the tutorial shape. That shape has a consistent bias, and once you can name the bias you can correct for it in one sentence of prompt.

The tutorial shape optimises for plausibility on first read. It is simple, synchronous, unpaginated, unversioned, single-region, and it assumes the happy path. That is genuinely the right default for a prototype, which is why it is so hard to notice when it is wrong. It becomes wrong the moment the thing goes in front of users, and by then it is load-bearing.

This is what Ng means when he writes that a novice who vibe codes “did not know such tradeoffs even existed and therefore did not steer the agent”. The failure is not that the agent chose badly. The agent chose the way a reasonable stranger would choose with no information. The failure is that nobody supplied the information.

3A requirement is a ranking, not a list

Product requirements arrive as features. Architectures are decided by the properties nobody wrote down. The translation between the two is a skill, and it is mostly a matter of asking three questions of every requirement.

Take a real sentence: “Users should be able to see their order history.” As written, this constrains nothing. Now ask:

1. What is the cost of being slow? A shopper waiting three seconds on an order history page is irritated. A trader waiting three seconds on a position page has lost money. Same feature, two orders of magnitude between the latency budgets.
2. What is the cost of being wrong? Showing an order that was cancelled two seconds ago is a support ticket. Showing a bank balance that is two seconds stale is a regulatory problem. This question is the one that decides your consistency model, and almost nobody asks it explicitly.
3. What is the cost of being down? If the page is unavailable for ten minutes on a Tuesday, does anyone lose anything? For a lot of internal tooling the honest answer is no, and that answer should save you a five-figure infrastructure bill.

The answers give you a ranking. The ranking gives you an architecture. Skipping to the architecture is how teams end up running multi-region active-active for an admin dashboard used by eleven people.

4The arithmetic of availability

Availability is the one property in the list with real arithmetic behind it, and the arithmetic is unintuitive enough that people get it wrong in both directions. Ten minutes here will save you from two expensive mistakes.

An availability figure is a probability: the share of requests that get a successful answer over some window. Write 99.9% as 0.999 and the arithmetic works out like this.

Components in series multiply. If your request must pass through a load balancer, an application server and a database, and each is independently available 99.9% of the time, the path is available 0.999 × 0.999 × 0.999 = 99.7% of the time. You did not build a 99.9% system. You built a 99.7% system out of 99.9% parts, and you tripled your downtime budget without adding a single feature.

// three dependencies, each "three nines"
const path = [0.999, 0.999, 0.999];
const available = path.reduce((a, b) => a * b, 1);
console.log(available);            // 0.997002999 -> 99.70%
console.log((1 - available) * 43200);  // 129 minutes down per 30-day month

Redundant components in parallel add nines. Two instances of a 99% service, where either one can serve the request, fail only when both fail: 1 − (0.01 × 0.01) = 99.99%. This is why redundancy is such a powerful lever, and also why it is oversold — the arithmetic assumes the failures are independent. Two instances in the same rack, on the same deploy, running the same bug are not independent at all, and the formula quietly becomes a lie.

The last piece of arithmetic is the one that governs behaviour rather than design. Convert the target into a downtime budget and it stops being an abstraction.

Read the bottom row again. Five nines allows five minutes of unavailability per year. One botched release spends the whole budget. If your product does not require that, asking for it is not ambition; it is an expensive way to make every future deploy frightening.

5One feature, three products

The clearest way to feel that there is no universal right answer is to build the same thing three times under three different rankings. Here is one feature — a counter of how many people are currently viewing an item — in three products.

Three defensible designs, three rankings, one feature. An engineer who has memorised “use a cache for counters” gets the ticketing site wrong. An engineer who has memorised “always be correct” gets the news site wrong and the dashboard very wrong.

6Writing the ranking down

Everything above collapses into one short artefact. It goes at the top of the design document, in the pull request description, and in the prompt. It is four to six lines long, and if it is longer than that nobody will read it, including the agent.

The shape that works:

# Order history page

Ranked constraints
1. A customer must never see another customer's data.        (non-negotiable)
2. Refund status must be current within 5s.                   (regulatory)
3. p95 under 400ms for the shopper path.                      (measured, not felt)
4. Correct under concurrent inserts.                          (no skipped rows)

Explicitly not constraints
- Availability beyond 99.9%. Down is a support cost, not a revenue loss.
- Cost at current scale. Under $200/month either way.
- The admin view's latency. Staff will wait.

Three properties of this document make it work. It is ranked, so conflicts have an answer. It has numbers, so “fast” cannot drift. And it says what is not a constraint, which is the half that stops both humans and agents from gold-plating.

The playground below is the exercise you will repeat in most chapters of this course: a scenario, its stated constraints, and a set of decisions that have to answer to them. Nothing scores you. The board only reflects your own ranking back at you, which turns out to be enough.

✓Checkpoint

Five questions. Answer before you scroll — the explanation is worth more when you have committed to something.

▶Playground

A real brief with a real ranking. Configure it, then open the defensible answer and see where you differ — and, more importantly, whether your reason was better than the one written down.

✓Exercise set

Twelve problems. The JavaScript ones run in a sandboxed frame and are checked against what your code actually does, so there is usually more than one right answer. The design ones are graded against the scenario’s stated constraints, and they require a written justification — naming the tradeoff out loud is the skill being assessed. Your work is saved in this browser.