Trade-off Statement

A team adds a cache and writes "improves performance" in the pull request. Eighteen months later prices change every ten minutes, customers see stale totals, and nobody can say whether the cache was supposed to tolerate that. A trade-off statement is the sentence that would have told them: what was gained, what was paid, and when to look again.

Why it matters

Every architectural choice buys one quality by spending another. Without a written price, the cost is invisible until it arrives as an incident, and the people who made the choice have moved on. A statement with numbers gives reviewers something to disagree with today and gives successors a test for when the assumptions have expired.

It also forces honesty. Writing "costs up to 60 s of stale prices" makes a team ask whether the business accepts that, which is a conversation worth having before the build, not after the complaint.

Implementation patterns

• Three slots: We choose X. It gains <quantity>. It costs <quantity>. Revisit if <observable condition>. Keep it to two sentences.
• Cost in business currency: stale price for 60 s, two more on-call hours a week, six weeks of delay, 4,000 dollars a month. "Complexity" alone does not count.
• Observable trigger: a metric, a date or a count that someone can check, such as "if price changes exceed hourly" or "if a second team consumes this queue".
• Where it lives: in the decision record next to the code, and as a comment on the configuration that implements it (the cache lifetime).
• Alert on the trigger when it can be measured, so the statement is watched rather than filed.

Industry example

A documented case of a decision with a stated price is the 2012 Pinterest talk on MySQL sharding (QCon San Francisco slides by Marty Weiner and Yashwanth Nelapati). The ID space allowed 65,536 shards and the first 4,096 were opened, running on 8 physical servers with 512 databases each. Put as a trade-off statement: embedding the shard in every object ID removes routing lookups and lets growth proceed by moving whole databases; it costs the ability to split an oversized shard, because data stays where it was created. The talk does not phrase it this way, so the framing is a reading of the design, not a quotation.

Failure scenarios

• Gain without cost: "improves performance" survives review because nothing in it can be wrong.
• Cost without number: "some operational overhead" hides an extra 10 hours a week of on-call until the team is exhausted.
• No trigger: a decision made for 5,000 users governs 5 million.
• Numbers invented for effect: a precise but fictional 93.4 percent gain. Use ranges and say they are estimates.
• Stored where nobody reads it: a record in a wiki page that no pull request links to.

Trade-offs

When not to use it

Skip the full form for decisions reversible in an afternoon, such as a log format or a library version inside one service. A single line in the pull request is enough. Writing statements for every small choice buries the ones that matter and trains people to fill in slots mechanically.

Interview question

Q: You inherit a system with a read cache, a message queue and a second region, and no records of why. How do you reconstruct the trade-offs?

What a strong answer covers: ask for the problem each component solved (read load, spikes, regional failure) and the numbers at the time; measure today's gain (hit rate, queue depth, failover test) to see whether it still holds; write the cost down in business terms; add a revisit trigger to each; and flag the ones whose original reason has disappeared as candidates for removal.

Quick check

Quiz: Which part of "the benefits outweigh the downsides" can a reviewer test? None: it has no number, no named cost and no trigger.

Flashcard: What are the three parts of a trade-off statement? — A gain with a number, a cost with a number, and a revisit trigger.