How should the reversibility of a decision change the process and rigour you apply to making it?

## The principle The rigour of a decision process should be proportional to the **cost of being wrong**, which for architecture is dominated by the **cost of reversal**, not the cost of implementation. Amazon popularised the shorthand: **one-way doors** (walk through and you cannot come back — decide slowly, deliberately, with senior review) versus **two-way doors** (you can walk back — decide fast, let the team own it, learn from reality). ## What makes a decision hard to reverse - **Data gravity**: data already stored in a shape or a system. Migrating terabytes with zero downtime is a project, not a change. - **Published contracts**: once external clients depend on an API or event schema, changing it requires versioning, dual support and a deprecation window measured in quarters. - **Semantic leakage**: consistency guarantees, ordering, idempotency and error semantics get baked into every caller's logic. - **Organisational entanglement**: team boundaries drawn around components; reversing means reorganising people. - **Commercial lock-in**: contracts, licensing, proprietary features with no equivalent elsewhere. - **Compliance and audit**: decisions embedded in certified processes cannot be changed unilaterally. ## Process for one-way doors 1. **Name it as one-way explicitly** — the classification itself is the most valuable step, and it is cheap. 2. **Enumerate at least two real alternatives** with consequences; a decision with one option is a rationalisation. 3. **Retire the biggest uncertainty with a spike or prototype**, measured against the relevant quality-attribute scenario rather than argued by opinion. 4. **Seek diverse review** — operations, security, and the teams who will live with it. 5. **Record it**: context, options, decision, consequences, assumptions, and what evidence would make you revisit. 6. **Look for a way to make it two-way first** — often the highest-value move available. ## Process for two-way doors Delegate. Set a default, a time-box and a guardrail ("any queue library that supports at-least-once delivery and has a named owner"), then let the team decide. Escalating these is the classic failure of centralised architecture groups: it creates an approval queue, teaches teams that decisions are someone else's job, and blocks learning. ## Converting one-way doors into two-way doors This is the underrated skill: - **Isolate** the choice behind an interface or anti-corruption layer so callers do not depend on its specifics. - **Version contracts** from day one, with a deprecation policy, so changing them is routine. - **Build migration capability** — dual-write, backfill, shadow-read and comparison tooling turn a data-model change from a heroic project into a runbook. - **Feature flags and gradual rollout** allow trying and retreating in production. - **Keep the blast radius small** — apply the decision in one bounded context first, prove it, then propagate. - **Automate verification** with fitness functions so a reversal cannot silently break other constraints. ## Cautions - **People overestimate irreversibility** and use it to justify analysis paralysis. Ask concretely: what exactly would we have to do, and how long would it take? - **People also underestimate it** for things that feel like details — identifier format, timestamp and timezone semantics, URL structure, event schema evolution rules, tenancy isolation. - **Option-keeping is not free.** Preserving reversibility everywhere is speculative generality; spend that budget only where uncertainty is real and consequences are large. - **Reversibility is time-dependent**: a decision may be two-way during a private beta and one-way the moment external customers integrate. The classification must be revisited, not assumed permanent.