Reversible vs Irreversible Decisions

A one-way door, Jeff Bezos's Type 1 decision, is one that is irreversible or very expensive to reverse: once you walk through, you cannot easily come back. Reversal would require large data migrations, breaking contracts with external consumers, retraining many teams or waiting out long commitments. Typical examples are the cloud provider, the primary database and data model, a shard key, public API and event contracts, and organisation-wide platforms such as an event backbone. Because mistakes are costly, these decisions deserve evidence such as proofs of concept and benchmarks, review by an architecture board, timing at the last responsible moment, and an ADR that records the alternatives and the estimated exit cost.

A two-way door, or Type 2 decision, is one you can reverse cheaply and quickly if it turns out wrong. Examples include a JSON library hidden behind a mapper interface, Redis TTLs and connection pool sizes, internal endpoint shapes changed on both sides together, EKS node types adjusted in a Karpenter NodePool, and new behaviour behind a feature flag that can be toggled off. Because the cost of being wrong is low, the right process is fast: the owning team decides, tries it, measures the result and reverses if needed, with at most a light ADR. Slowing these decisions down with committees costs more than any mistake the committee could prevent.

One-way doors include the primary database and data model, for example moving orders from Aurora to DynamoDB, which would mean a large data migration; a public REST v1 contract, where removing a field breaks external partners; the orders shard key; an event backbone or identity provider that many teams build on; and long financial commitments such as three-year Savings Plans. Two-way doors include a JSON library behind an interface, a thread pool size or cache TTL, an internal endpoint shape, an instance type, and a new pricing engine released to a 5 percent cohort behind a flag. Some sit in a grey zone: Kafka for internal events becomes harder to reverse as producers multiply.

Because reversibility is the best single signal for how much rigour a decision needs, and rigour is expensive. A uniform process is always wrong for someone: heavy enough for a shard key, it buries teams in committees for library swaps; light enough for a library swap, it lets a public contract or data model be chosen carelessly. Classifying by door type lets you spend evidence, review and documentation only where reversal would be costly, and push everything else to teams to decide quickly. In the note's example, routing only one-way doors to the architecture board cut its agenda time by 60 percent, while the shard key decision got a three-week evaluation and a pilot.

You buy reversibility by adding mechanisms that lower the cost of undoing a choice. Seams such as ports and adapters keep domain code dependent on an interface like OrderEventPublisher, so replacing Kafka with EventBridge means writing a new adapter rather than touching every caller. Feature flags through OpenFeature or AWS AppConfig let new behaviour be switched off instantly. Expand–contract schema changes add the new column, write both, backfill and switch reads, delaying the irreversible drop for weeks. Pilots and cohort rollouts, such as 5 percent of customers, and parallel runs comparing old and new tax calculations reveal problems before full commitment. Each mechanism has a cost, so use them where volatility justifies it.

The last responsible moment is the latest point at which you can make an irreversible decision before delaying it starts to cost more than the information you gain by waiting. The idea comes from lean software development. It applies to one-way doors: delay the commitment, but use the time to reduce uncertainty through spikes, pilots, benchmarks and access-pattern analysis, so the decision is made with evidence. ShopNow, for example, chose its disaster-recovery region only after latency tests. It is not an excuse for procrastination, because waiting too long lets a deadline make the decision for you. It also does not apply to two-way doors, which should simply be tried now.

The most common mistake is not rushing one-way doors, as people expect, but treating two-way doors as one-way. Many organisations send every technical choice through the same heavy review, so a team waits weeks for permission to swap a retry library inside one service, as in the note's five-week Spring Retry to Resilience4j example. The damage is larger than the delay: teams stop experimenting, work around the process, and review boards spend their time on trivia instead of the genuinely irreversible decisions. The fix is to classify each decision, give teams the right to make two-way decisions with a light ADR, and reserve board time for one-way doors.

I would make reversibility the routing rule for decisions. Every ADR states its door type and, for one-way doors, an estimated exit cost. Teams own two-way doors outright and record them in a light ADR, so they can move quickly. One-way doors go to the architecture review board, whose charter covers only those, and require evidence such as proofs of concept, benchmarks, a pilot or a parallel run, with the decision timed at the last responsible moment. Platform standards provide seams, feature flags and expand–contract migrations so more decisions become two-way. Finally, classifications are reviewed periodically, because doors close as adoption grows, and decision lead time is tracked to prove the process stays fast.