The Cost of Architectural Decisions: Reversibility as a Quality
What This Concept Is
Every architectural decision has two costs:
- the cost of living with it if it turns out to be right (ongoing operational or complexity cost)
- the cost of backing out of it if it turns out to be wrong (reversal cost)
The reversal cost is sometimes called reversibility, and this concept treats it as a first-class architectural quality - something to be explicitly measured, documented, and optimized the same way you would optimize performance or modifiability.
Jeff Bezos's framing is the most widely used shorthand: decisions come in two shapes.
- Two-way door. Cheap to back out of. Costs a sprint or less. Examples: logging library, internal metrics client, which validation framework.
- One-way door. Expensive to back out of. Costs quarters or years. Examples: primary database engine, public API shape, wire serialization format, multi-region sharding strategy.
Treating reversibility as a quality means: the architecture itself is optimized to keep as many decisions as possible in the two-way-door category. When a decision must be one-way, the architecture pays additional attention to it.
Why It Matters Here
Uniform architectural discipline - treating every decision with the same weight - kills projects. Two failure modes:
- Over-reviewing two-way doors. Six stakeholders weigh in on which HTTP client library the team should use, while a genuinely one-way decision (wire format choice) is made in a hackathon.
- Under-reviewing one-way doors. "We picked GraphQL in a sprint and now it is the company platform."
Reversibility as a quality is the lever for matching review weight to decision weight. It is also the backbone of evolutionary architecture: a system that keeps decisions reversible can adapt; one that locks in many one-way doors cannot.
Concrete Example
Consider a streaming-service architect facing three decisions in the same week.
Decision A: Which observability vendor.
- Reversal cost: ~2 sprints (swap SDK, rewrite dashboards, re-train team).
- Door: two-way. Pick the one that fits current usage. Revisit if the vendor becomes expensive.
Decision B: Which wire format for video-event pipeline.
- Reversal cost: migration plan, coordinated client updates across internal and partner systems. ~6 months.
- Door: one-way. Warrants ATAM-style review, explicit alternatives, and an ADR with a "conditions to revisit" section.
Decision C: Which language for a new analytics service.
- Reversal cost: depends. If it is one small service, replaceable in a sprint. If it becomes the shared analytics platform, the cost compounds.
- Door: starts two-way, drifts toward one-way. The architect's move: keep it in the two-way zone by bounding the service's scope (one team, one domain) until enough is known.
Now consider reversibility as a quality of the architecture itself. Two shapes of the same system:
| Property | High-reversibility design | Low-reversibility design |
|---|---|---|
| Wire format | Schema-registered, versionable (Protobuf + schema registry) | Ad-hoc JSON across 40 services |
| Data ownership | Clear per-service, with well-defined export/import | Shared databases, joins across services |
| Integration | Contract-versioned APIs with deprecation discipline | "Just call our endpoints" |
| Runtime | Feature-flagged rollouts with instant revert | All-or-nothing releases |
Same product, different reversibility profile. The high-reversibility version costs more up front; it saves on every wrong decision the team will inevitably make.
Common Confusion / Misconception
"Reversibility means everything is easy to change." No architecture makes every decision reversible. Reversibility is a portfolio property: how many of your critical decisions are in the two-way class versus the one-way class.
"If it ships, it's one-way." Wrong. Shipping something behind a flag, measuring for a week, and removing it is perfectly ordinary. Shipping is not locking in.
"Optimizing for reversibility is pessimism." It is humility. You will be wrong about some decisions. The question is whether the system lets you correct them.
"One-way doors should be avoided." Some decisions must be one-way (e.g., a regulatory data-locality commitment). You do not avoid them; you recognize them and weight them appropriately.
How To Use It
Every ADR (introduced seriously in Module 5) should have a door classification at the top. Two sentences:
Door: one-way.
Reversal cost estimate: ~2 quarters (coordinated wire-format migration across 4 consumers, training, and data backfill).
For the architecture as a whole, run a reversibility audit twice a year:
- List the top 10 architectural decisions of the last 12 months.
- Classify each as one-way or two-way.
- For every one-way decision, list the explicit conditions under which you would revisit it.
- For every decision drifting toward one-way (scope creep, consumer lock-in), name what would keep it two-way.
The audit is the shortest meeting you will have all quarter; it is also one of the most useful.
Check Yourself
- Classify as one-way or two-way: (a) choice of cloud provider; (b) URL path versioning for a public API; (c) adopting OpenTelemetry; (d) picking a CI/CD platform.
- Name a decision your team treated as one-way that was actually two-way. What did over-caution cost?
- Name a decision your team treated as two-way that was actually one-way. What did under-caution cost?
- Why does optimizing for reversibility sometimes cost simplicity?
Mini Drill or Application
Take the last 10 architecture-sized decisions from your system's history. For each:
- classify door (one-way / two-way / started two-way and drifted)
- estimated reversal cost in time and money
- was the review weight at the time matched to the door?
- if misclassified, what was the damage?
Then name one thing in the current architecture you would change to increase portfolio-level reversibility. If you cannot name one, the system is probably locked in in ways you have not admitted.