How should the reversibility of an architectural decision change how much effort you spend choosing, and how do you keep a style choice evolvable over time?

### Reversibility as the effort dial Not all architecture decisions deserve equal ceremony. A widely used framing distinguishes **two-way doors**, which can be walked back cheaply, from **one-way doors**, which cannot. A related point often attributed to Martin Fowler is that the architect's job is largely to *reduce irreversibility* — to convert one-way doors into two-way doors where possible. Examples of two-way doors: a logging library, a cache technology, internal code layout, a CI tool. Examples of one-way doors: splitting one datastore into several owned by separate services; publishing an external API contract that third parties depend on; choosing eventual over strong consistency in a domain handling money; a datastore with no realistic migration path; and the module boundaries themselves, once teams and data have grown around them. The operational rule: spend evaluation effort proportional to (cost of reversal) times (probability of being wrong). Analysing a two-way door for three weeks is waste; prototyping it for two days is not. ### Last responsible moment From lean thinking: delay a decision until the moment beyond which delaying further would eliminate an important option. The point is not procrastination — it is that information accumulates. A month into building you know real load shapes, real domain boundaries and real team capacity, all of which improve the decision. What makes deferral safe is keeping the decision *isolated*: hide the volatile choice behind one boundary so changing it later touches a small area. The failure mode is over-applying this into speculative generality — abstracting everything 'just in case', which adds indirection now for flexibility that is usually never used. Abstract at the boundary you have concrete evidence is volatile; elsewhere, commit. ### Keeping the choice evolvable 1. **Enforced boundaries.** Modularity is what makes later change affordable: one module per capability, an explicit public surface per module, no cross-module table access, and automated architecture tests that fail the build on a violation. Boundaries that are documented but not enforced erode within months. 2. **Fitness functions.** Automated checks that the chosen characteristics still hold — latency budgets asserted in load tests, dependency rules asserted in architecture tests, failover time asserted by a chaos experiment, budgets on bundle size or startup time. This is the core of *evolutionary architecture*: guided change, where the guides are executable. 3. **Incremental migration.** When the style must change, avoid the big-bang rewrite, which competes with a moving target and delivers nothing until the end. Instead use the **strangler fig** — put a facade in front, route slice by slice to the new implementation, delete the old slice when its traffic reaches zero; **branch by abstraction** — introduce an abstraction over the old implementation, build the new one behind it, switch by configuration; and **expand/contract (parallel change)** for schemas and APIs — add the new shape, write to both, migrate readers, then remove the old shape. Add dark launches and shadow traffic to validate the new path under real load before it serves users. 4. **Revisit triggers.** State in the ADR the observable condition that reopens the decision: a scale threshold, a team-count threshold, a cost ceiling, a regulatory change, a latency budget consistently breached. This makes evolution evidence-driven rather than politics-driven. ### Traps at this level The sunk-cost trap: continuing with a style because of what has already been spent rather than the cost from here forward. The rewrite trap: assuming a clean slate is cheaper than incremental change — it rarely is, because the old system encodes years of undocumented edge cases. The premature-distribution trap: paying microservice costs for optionality you never exercise. And the frozen-architecture trap: no fitness functions, so the system quietly drifts until the documented architecture and the real one have nothing in common.