Decisions that do not swing back

The ratio changed, not the doors

Sort every decision by what reversing it costs.

A two-way door can be undone in an afternoon. The name of an internal function, the structure of a module, which library formats your dates, how a handler is organised. These were never expensive, and generation made them cheaper still: you can now try the alternative rather than argue about it.

A one-way door costs weeks or months to reverse, and sometimes cannot be reversed at all because other people depend on it. These did not get cheaper by a single percent.

So the ratio moved sharply, and the practical consequence is uncomfortable for most teams: you should now spend more of your deliberation on fewer decisions. Time argued over a module layout is time taken from the decision that will still be hurting in 2030.

What is actually a one-way door

Your public interface. Once a third party calls it, the shape is fixed until you can make them all change, which for a paying customer means never. This includes webhook payloads and anything in a URL.

Your primary key scheme. Integers, UUIDv4, UUIDv7, ULID: pick wrong and you find out at scale. Random UUIDs as a clustered primary key scatter inserts across the index and fragment it; time-ordered identifiers do not. Reversing this on a table with fifty million rows and eleven foreign keys is a multi-week migration with downtime risk, and every integration that stored your identifiers is now affected.

How you represent time. Storing local time without a zone, or storing an instant when you needed a calendar date, or assuming offsets are stable. Timezone rules change by government decree; a stored offset is a fact that expires. Correcting this later means reinterpreting historical data you can no longer interpret.

Your tenancy model. One database per customer, or one database with a tenant column, is a decision made in week one that determines what your compliance story, your noisy-neighbour behaviour and your per-customer restore look like for a decade.

Your authentication and identity model. Whether a user can belong to two organisations. Whether identity is an email address. These propagate into every table.

What you collect. Data you gathered without a basis is a liability that does not go away by deleting the column, and data you failed to collect cannot be recovered retrospectively.

Synchronous or event-driven. Changing the fundamental interaction style of a system touches everything.

The question to ask out loud

Before a design decision, one sentence:

If this is wrong, what does it cost to change in eighteen months, when there are four hundred thousand rows, three external integrations and nobody here who wrote it?

An afternoon means decide fast and move. Six weeks means stop, write it down, get a second reader, and consider whether you can defer the decision until you know more.

Deferring is a real option

The strongest move on a one-way door is often not to decide well but to not walk through it yet.

Do not publish the API to third parties until the shape has survived two internal consumers. Keep identifiers opaque so that you can change what is behind them. Write the adapter that isolates the choice, so the decision is made in one file rather than in four hundred. Ship the version that has less in it.

This is cheaper than it used to be, because implementing two candidate designs to see which one is awkward is now an afternoon rather than a fortnight. That is the new option and it is under-used: build both, throw one away, keep the knowledge.

Why generation makes the one-way doors riskier

One specific hazard, worth naming.

An irreversible decision, made implicitly, now propagates much faster than before. The model picks an identifier scheme and a time representation because it must pick something, and it picks whatever is most common. Two weeks later there are ninety files depending on it, and the decision nobody made is now load-bearing.

The cost of a wrong one-way door was always the same; what changed is how quickly you get through it without noticing. So the check belongs at the start of a piece of work, not at review, and the specification lessons in module four are where it lives: the decisions worth writing down are exactly the ones whose door does not swing back.

The caveat

The two-way and one-way distinction is a heuristic, not a taxonomy. Doors vary by context: a public API with three internal consumers is a two-way door; the same API with three thousand paying customers is welded shut. And people over-apply it, classifying everything as irreversible in order to justify delay, which is its own failure mode. The question is not whether reversal is possible. It is what reversal costs, in the situation you will actually be in.