Reversible vs Irreversible Decisions
Sort architectural decisions by the cost of changing your mind, then match the depth of deliberation to that cost instead of treating all choices as equal.
Teams often spend the same energy debating a logging library as they do choosing a primary database. That is a miscalibration. The most useful question you can ask about any decision is not "is this the best option?" but "what does it cost to undo this?"
Two kinds of doors
Jeff Bezos popularised the idea of one-way and two-way doors. A two-way door can be walked back through: if the result is bad, you return and try another. A one-way door cannot, or only at great expense. Architecture contains both, and the skill is telling them apart quickly.
| Decision | Reversal cost | Door | |---|---|---| | Internal library for date handling | Hours | Two-way | | REST framework behind an adapter | Days | Two-way | | Public API response shape | Months, with client coordination | One-way | | Primary datastore and data model | Months to years | One-way | | Cloud provider with proprietary services | Quarters | Mostly one-way | | Event schema published to other teams | Months | One-way |
What makes a decision hard to reverse
Reversal cost is driven by a few factors, and you can score a decision against them:
- Data gravity. Once data accumulates in a format, migrating it requires backfills, dual writes and verification.
- External dependents. Anything consumed by people you cannot easily contact (public APIs, partner integrations, mobile apps in the wild) is sticky.
- Blast radius. A change that touches every service is harder to roll back than one confined to a module.
- Skills and hiring. A language or paradigm shapes the team for years.
- Contractual lock-in. Multi-year commitments make switching financially painful even when technically easy.
Spend deliberation proportionally
For two-way doors, decide fast, with whoever is closest to the problem, and instrument the result. A one-paragraph note is enough. For one-way doors, slow down: write a decision record, list alternatives, run a spike, and seek a second opinion.
A rough policy that works in practice:
Cost to reverse < 1 engineer-week -> owner decides, no review
Cost to reverse < 1 engineer-month -> owner decides, informs the team
Cost to reverse > 1 engineer-month -> written proposal, review, record
Turn one-way doors into two-way doors
You often cannot avoid a commitment, but you can lower its price. Common techniques:
- Put an adapter in front. Wrap a vendor SDK in your own interface so replacing it touches one module.
- Version from day one. An API with a version prefix and a deprecation policy is far cheaper to change than an unversioned one.
- Use expand and contract migrations. Add the new column, dual write, backfill, switch reads, then remove the old column. Each step is individually reversible.
- Ship behind flags. A feature flag converts a deployment into a reversible switch.
- Pilot narrowly. Run the new datastore for one low-risk workload before betting the platform on it.
Defer irreversible choices until you must
If a decision is a one-way door, ask whether it must be made now. The last responsible moment is the point after which delaying costs more than deciding. Before that moment, you learn things for free. A team that picks a sharding scheme before it has real traffic patterns is guessing; a team that waits until the first hot partition appears is deciding with data.
Deferral has limits. Do not postpone so long that the decision gets made implicitly by whoever writes the code first. Set a date, name an owner, and say what evidence would settle it.
A common failure mode
The inverse mistake is equally costly: treating a one-way door casually because the team is moving fast. A shortcut like storing user identifiers as auto-incrementing integers and exposing them in URLs looks like a two-way door on day one. By year three it is embedded in bookmarks, partner systems and analytics, and changing it is a migration project. When a decision touches identifiers, public contracts or stored data formats, assume it is one-way until proven otherwise.
Key takeaways
- Classify decisions by reversal cost, not by how important they feel.
- Decide two-way doors quickly and locally; slow down for one-way doors.
- Data, external consumers, blast radius and lock-in make decisions sticky.
- Reduce commitment cost with adapters, versioning, flags and expand and contract migrations.
- Defer irreversible choices to the last responsible moment, but set a date so deferral does not become drift.