Part VI · Chapter 12 · The Decisions · lesson 1

Which of these decisions can you take back?

13 min

Builds on Say what would change your mind, before you look at options

Five things on the whiteboard this sprint: the cloud provider, the database engine, the URL shape of the new public API, the queue library, and whether customer IDs are sequential integers or opaque strings.

Somebody has booked one two-hour meeting for all five.

Four of them are the wrong length of meeting. Before you read on: which of the five would be hardest to take back once real traffic is on it?

Predict

Cloud provider, database engine, public URL shape, queue library, identifier format. Which is hardest to reverse after launch?

The cloud providerThe database engineThe URL shape of the public APIWhether customer IDs are sequential integers or opaque strings

The test, which is not about size

A decision is one-way to the extent that somebody else holds a copy of its output, or the information it threw away is gone.

That is the whole test, and it has nothing to do with how much the component cost or how senior the person who chose it was. Three things make a decision genuinely hard to take back:

Copies outside your control. Identifiers, URL paths, webhook payload shapes, exported files, published documentation, emails already sent, data shared with a partner. You can stop producing them. You cannot un-produce them.

Information you destroyed or never recorded. The event you did not log, the field you coarsened to save space, the precision you rounded away, the consent you did not capture at signup. Reversing this needs a time machine, not a migration. This is the category people miss most often, because it does not feel like a decision at the time — it feels like a schema.

Commitments with other people's names on them. A signed contract, a published price, an announced deprecation date, a three-year compute commitment, a promise in a security questionnaire. Reversible only by asking somebody outside your team, which means it is not on your schedule any more.

Notice what is absent from that list: technology. Almost every technology choice is reversible at a cost measured in engineer-weeks, and engineer-weeks are exactly the resource you are trying to protect by deliberating. That is the trap. The deliberation is drawn to the components, because components are what architecture arguments are made of, and the one-way decisions are hiding in the schema and the API surface, where nobody has booked a meeting.

Four classes, and the only field that matters is the third one.

Two-way and cheap. Undoing it is a pull request. The queue library is here. Decide it in the stand-up; a two-hour meeting costs more than the mistake.

Two-way and dear. Undoing it is a project — a migration, a dual write, a backfill, a cutover. Weeks to a quarter, all of it yours. This deserves a written criterion and a reversal trigger, not a month of argument.

One-way in effect. Undoing it requires somebody outside your team to act: a customer to change their integration, a vendor to amend a contract, a partner to re-import. The cost is not large; the schedule is not yours.

One-way. The information is destroyed, or the copies cannot be recalled.

The third and fourth classes are where the month goes. In most sprints they contain zero items or one.

Not the same thing

Reversible at a cost you can schedule

Undoing it is work your own team can plan, start and finish without anyone outside the company agreeing to anything, and nothing has been destroyed in the meantime.

Measured in: Engineer-weeks to undo, plus the number of people outside your team who must act — which for this side is zero
For example: Moving a service off a managed queue onto a database table with a status column: a fortnight of work, a dual-write window, and the messages are all still yours the whole time.
Chase it alone and: Treating it as one-way. The team spends a month deciding something it could have decided in a day and tested in a week, and the month is drawn from the same budget the undo would have cost.

One-way, in effect or in fact

Undoing it needs somebody outside your team to change something they control, or needs information that no longer exists anywhere.

Measured in: Whether a copy of the output is held by a party you cannot instruct, and whether the discarded information can be recomputed from anything you still have
For example: Issuing sequential customer IDs for two years. Changing the scheme now means every partner, invoice and bookmark holds an identifier you can never withdraw, so you keep both schemes forever.
Chase it alone and: Treating it as two-way. It ships in an afternoon because it looked like a schema choice, and the cost arrives as a permanent compatibility tax that nobody ever attributes back to the afternoon.

Which is which? Put each one on a side.

Picking one relational engine over another for a service that has no users yet
Publishing the webhook payload shape to forty integration partners
Coarsening stored event timestamps from millisecond to hourly precision to shrink the table, with no archive of the originals
Announcing a deprecation date for an endpoint to customers in writing
Choosing which cloud region the first cluster lives in

What to do with the ones that are actually one-way

Here is the part that changes how the meeting goes, and it is not "think harder".

You do not get good at making irreversible decisions. You get good at making them reversible. The month is not for being more certain. It is for buying back the undo button, usually cheaply, almost always with indirection.

The identifier case, concretely. Sequential integers internally, and an opaque external handle for anything that leaves the building, with a mapping table between them. Roughly a day of work at the start of a project. What it buys: the public identifier becomes something you issue rather than something you leak, so adding a second format, rotating one, or stopping the enumeration of your own customer count in your URLs all become ordinary two-way decisions.

The same move, elsewhere:

An API version prefix from the first endpoint, which costs nothing and turns "we can never change this shape" into "we can change it once, loudly".
A tenant key on every row from the first migration, even with one tenant. Adding a partition key to a populated table is one of the dearest migrations there is; adding it when the table has a thousand rows is a morning.
Writing the raw event before the derived summary, because the summary is a two-way decision for exactly as long as its input still exists.
Capturing consent and provenance at the point of collection, since every later question about what you may do with a record is answerable from a field you either wrote or did not.

Every one of those is cheap at the start, dear in the middle, and impossible at the end. That curve — not the size of the component — is what deserves the month.

What would you do

You are two weeks from exposing the first public API. One launch partner is waiting on it and has written half their integration against your staging environment already. Internally, customers have had sequential integer primary keys since the first migration, and those integers are currently what the staging endpoints return.

Nobody is sure yet whether the identifiers will matter. They will be in URLs, in webhook bodies, and in whatever the partner stores on their side.

Optimising for: Ship the public API inside the two weeks already promised to a launch partner, while keeping the cost of being wrong about the identifier scheme under one engineer-week.
You cannot know: Whether any future customer will object to their account volume being inferable from a sequential identifier
Whether the partner will store the identifiers or re-fetch them, which their own code decides and you cannot see
How many more partners there will be in a year, which is the number that sets the cost of a later change
Whether a merger or a tenant split will ever require two records to share an external identity

Ship the sequential integers and revisit if anyone complainsSwitch the primary keys to opaque sortable strings everywhere before launchKeep integers internally, add an opaque external handle with a mapping table, and expose only the handleDelay the launch two weeks and decide the identifier strategy properly

Sort your own, this afternoon

This is twenty minutes and it is the artefact. List every decision your team currently has open — the ones in documents, the ones in a channel, and the ones somebody is quietly implementing. Then fill in four columns for each.

DECISION          | HOW YOU WOULD UNDO IT        | HOW LONG | WHO OUTSIDE THE TEAM MUST ACT
------------------+------------------------------+----------+------------------------------
queue library     | revert the branch            | 1 day    | nobody
cloud region      | migrate, transfer, cut over  | 1 quarter| nobody
webhook field set | version 2, support both      | forever  | 40 partners, on their schedule
event precision   | cannot: originals discarded  | never    | n/a
deprecation date  | publish a new date           | 1 week   | every customer who planned for it

The fourth column is the one that does the work. If it says "nobody", the decision belongs in the stand-up however large it feels. If it names anybody, it belongs in a document with a reversal trigger, and the first question in that document is not "which option?" — it is "what indirection makes this reversible, and what does it cost?"

Then count the rows where the third column says never or forever. On a normal sprint's list the answer is zero or one. If you have five, either you are at an unusual moment — a public launch, a data model being set, a contract being signed — or you have mistaken expensive for irreversible, which is the error this lesson exists for.

Check

A team is choosing how to store uploaded files. Which part of that decision is the one-way part?

Which object store provider holds the bytesWhether the download URLs handed to customers are permanent and guessableWhich image sizes get generated on uploadWhether uploads go through your application or straight to the store

Why 'move fast on reversible decisions' keeps producing the oppositeOptional

The two-class version of this idea is well known enough that most teams can recite it, and reciting it often makes things worse, for a mechanical reason: the sorting is done by whoever is most senior, in a meeting, from memory, and the cues available in a meeting are cost and prestige rather than copy count. So the cloud provider gets the quarter of deliberation, and the identifier format gets none, because it was one line in a migration decided by whoever typed the migration.

The cheap fix is the fourth column. "Who outside this team must act for us to undo this?" is a question a junior engineer can answer about somebody else's decision in ten seconds, it does not require knowing what anything costs, and it puts the schema change and the invoice line in the right boxes without anybody having to win an argument about importance.

The other half is to stop asking "is this reversible?" as though it were a property of the decision. It is a property of the decision plus the indirection you are willing to build, and almost every one-way decision in a young system has a one-day indirection that converts it. Finding that indirection is the actual senior skill here, and it is much more teachable than judgement.

As of 2026-10-31

Current as of 31 October 2026, and two specifics here have a shelf life. The advice to use a sortable opaque identifier rather than a random one reflects where the consensus sits at this date: UUID version 7 is standardised and widely available in recent database and runtime versions, so the index-locality argument that used to favour integers is much weaker than it was, but check what your engine version actually generates and indexes rather than assuming. The claim that a cloud or region migration is "a quarter" assumes managed services with public equivalents on both sides; it does not hold for anything built on a provider-specific product with no analogue elsewhere, and the list of those products changes every year. The reversibility test itself is not dated — it is about who holds copies, and that has been the same since people started issuing invoice numbers.

Worth remembering

A decision is one-way to the extent that somebody outside your team holds a copy of its output, or the information it discarded is gone — not to the extent that it was expensive.
Three sources of one-wayness: copies you cannot recall, information you destroyed or never recorded, and commitments with other people's names on them.
Almost no technology choice is on that list. Most are migrations: dear, dull, and on your own schedule.
The destroyed-information case is the one teams miss, because it arrives as a storage optimisation in a sprint rather than as a decision.
Sort your open decisions by one question: who outside this team must act for us to undo it? 'Nobody' means decide it in the stand-up, whatever it costs.
You do not get better at making irreversible decisions. You buy back the undo button, usually with a day of indirection — an external handle, an API version prefix, a tenant key, the raw event kept beside the summary.
That indirection is cheap at the start of a project, dear in the middle and impossible at the end, and that curve is what deserves the long deliberation.
On a normal sprint's list, zero or one decisions are genuinely one-way. Five means you have mistaken expensive for irreversible.

Where this stops holding

The sort assumes you get to look at the decision before anything has acted on it, and there is a class of change where the undo button exists, works, and still cannot be pressed.

A schema migration that drops a column is a revert in Git and an impossibility in production. Relaxing a rate limit is one line to tighten again, except that customers built against the higher limit within a week, so tightening it is a breaking change you announced by accident. In each case the code is two-way and the effect is one-way from the moment traffic touches it.

So the crossing is this: when the first request that arrives under the new behaviour creates a copy, a dependency or a destroyed row, the decision became irreversible at deploy time rather than at decision time, and the four columns above are being filled in too late to help. Those changes need the thing this lesson has otherwise been quiet about — a staged rollout, a shadow write, a flag with a kill switch tested before it is needed — and the test for whether you need that machinery is exactly the fourth column, asked about the first hour after deploy rather than about next quarter.