Reasoning Under Uncertainty

Definition

Every architectural decision is made with incomplete information. The skill is not eliminating uncertainty but deciding well despite it.

Classify the uncertainty first

• Resolvable cheaply. A two-day spike answers it. Most performance and integration questions are here, and arguing about them for two weeks instead of measuring for two days is a common and expensive error.
• Resolvable expensively. A month of work would answer it. Worth doing only if the decision is irreversible and consequential.
• Irreducible. Future traffic, competitor behaviour, the business's direction. No amount of analysis helps; design for optionality instead.

Most debated uncertainty is in the first category and is being treated as though it were in the third.

Match the decision to the reversibility

Two-way doors — reversible in days or weeks — deserve a quick choice and an experiment. Spending three weeks deliberating something you could undo in a day is a real and common waste.

One-way doors — the primary data store, the tenancy model, the shard key, a public API contract — deserve deliberation proportionate to their cost.

The most valuable move is frequently converting a one-way door into a two-way one: an abstraction at the boundary, verified data portability, a migration path proven at small scale.

Designing for irreducible uncertainty

• Preserve optionality where it is cheap. Do not commit to a shard key before you understand the access patterns.
• Delay the irreversible decision to the last responsible moment — the point after which delaying costs more than deciding.
• Design for a range, not a point estimate. If traffic might be 10x or 100x, ensure the design is adequate at 10x and can be extended at 100x, rather than optimising for a number nobody knows.
• Write down the assumption and its trigger, so you notice when it breaks: "we assumed under 100,000 tenants; revisit at 50,000".

Communicating it

State uncertainty explicitly and quantify where possible. "We are confident about the read path; the write path assumes a peak of X, which we have not observed above X/3." Concealed uncertainty is discovered later and costs credibility; stated uncertainty is credible and invites help.

Failure scenarios

• Analysis paralysis on a reversible decision.
• Deciding fast on a one-way door because the team wanted momentum.
• A point estimate treated as fact.
• Assumptions unrecorded, so nobody notices when they break.

Interview question

"How do you decide when you have enough information to make an architectural decision?"