An architecture decision must be made when the workload, scale and requirements are genuinely unknown. What approach works?

The approach

Optimise for the ability to change your mind, not for being right.

When the future is genuinely unknown, the value of a decision lies less in its correctness than in how cheaply it can be revised. Concretely:

1. Prefer reversible options, even at some efficiency cost. A design you can change in a sprint is worth more than a marginally better one you cannot.

2. Defer irreversible decisions to the last responsible moment — and define the trigger that says the moment arrived. "We will look at it later" is deferral without a trigger, which is indistinguishable from neglect and is discovered by customers.

3. Keep options open cheaply. Sometimes a small amount of work now — an interface, a job handle in a response shape, a routing layer — preserves an option at trivial cost. That is what buys the right to defer.

4. Make choices as configuration rather than code where the decision will change repeatedly. A routing layer that selects a model, a provider or an implementation means the decision can change without a deployment, and comparison on real traffic becomes possible.

5. Instrument the assumptions. Record the numbers the design was sized against, and alert on the assumption rather than only on the symptom it eventually produces.

The specific pattern for a fast-moving domain

An evaluation harness is the durable capability, not the current choice. Where the technology landscape changes quickly, what matters is the ability to re-evaluate cheaply: a held-out set, a comparison harness, and traffic-based comparison for the final check.

Without that, an organisation runs whatever it chose originally, indefinitely, because it has no way to know whether anything better exists for its workload.

What not to do

Design for the largest plausible scale. It pays complexity every day for a future that may not arrive, and frequently the scale that does arrive has a different shape than the one designed for — so the complexity was paid and does not fit.

Or refuse to decide. An undecided architecture is worse than either option, and the decision gets made by whoever writes the first line of code.