Two-Way Door
A decision that can be undone cheaply, and which therefore warrants a fast decision by the people closest to the work rather than extensive analysis.
The framing, popularised at Amazon, that most usefully sorts architectural decisions: a one-way door is expensive or impossible to reverse; a two-way door is not.
The consequence is procedural rather than technical. Two-way doors should be decided quickly, locally, and revised on evidence — a library choice, an internal API shape, a caching layer, a deployment configuration. Spending three weeks of senior time analysing something you could change next month is a misallocation of the scarcest resource available.
One-way doors deserve the analysis, the prototype and the written record: a data model that will hold years of records, a partitioning key, a public API contract, a vendor commitment with a long term, a regional topology, a programming language for a large codebase.
Two refinements that matter in practice:
Most decisions are less permanent than they feel. Teams routinely treat two-way doors as one-way and slow themselves down accordingly. Asking "what would it actually cost to undo this?" frequently produces a smaller number than expected.
Doors can be widened. An adapter around an external dependency, a feature flag, an interface that admits a second implementation — each converts a one-way door into a two-way one, and doing that is usually more valuable than being right the first time.