Solution strategy — five moves and what you deferred

Every bullet needs the quality goal it serves in the same line. "Event-driven ingestion" is a preference; "event-driven ingestion so a partner outage cannot fail a checkout (QG-1)" is a strategy. The difference is not phrasing — it is whether anyone can tell, later, what would make the move wrong.

Which is the test worth applying to a draft: for each bullet, name the goal that would have to change for you to reverse it. A move with no such goal is either a decision hiding in the wrong file or a technology someone wanted to use, and both are cheaper to catch here than in the third quarter of building it.

This also fixes the ordering. Because quality goals are ranked, the moves inherit the ranking, and the first bullet is the one that shaped the most. A strategy where all five bullets feel equally important is describing a system with no priorities.

Strategy is an index into the decisions, not a place to argue for them. The bullet says what the move is and cites an ADR; the ADR carries the options, the rejections and the consequences. Keep that split and the page stays readable for years.

So when a strategy section runs to five pages, the content is not the problem — the location is. Somebody argued a decision inside it, which means that argument is now unversioned, unciteable and invisible to anything that reads decisions by id. Move it out, leave a line behind.

The other cause of length is a strategy that has become a component list. Once every subsystem gets a paragraph, the page is competing with the structure concern and losing, because structure can be read off the code and strategy cannot.

Two-way doors — a library, a queue's retention setting, an internal module boundary — should be decided fast and cheaply, because being wrong costs an afternoon. One-way doors are the ones a strategy exists for: the data model, the tenancy model, the consistency guarantee you publish to consumers, the platform you buy your identity from.

Spend the argument where reversal is expensive, and say which kind each move is. A strategy that treats every choice as momentous is slow; one that treats every choice as cheap eventually ships a schema it cannot migrate. Naming the door is a one-word field that tells a reader how much scrutiny the bullet already had.

The judgement that matters is not "is this reversible" in the abstract but "reversible after how much data and how many consumers". Almost everything is a two-way door in week one. Record the point at which it stops being one.

Multi-region, a second database engine, a permissions model richer than roles, an internal platform. The right answer is often not yet, and not yet is a legitimate strategy entry — as long as it comes with the signal that would change it.

The trigger is what separates a deferral from an oversight. "Not multi-region yet" reads as ignorance to anyone who arrives later; "not multi-region until a contracted customer requires an in-region RPO, which C-3 says is 2027 at the earliest" reads as a decision, and it tells the next person exactly what to watch.

Write what the deferral costs you too, because deferrals are not free — they are usually a known ceiling. A single region caps availability; roles-only permissions cap which deals you can close. A ceiling nobody wrote down is a ceiling somebody promises past.

Start from one deployable unit with enforced internal boundaries, one managed relational store, one region, and a queue for the work that must not happen in the request. That shape is well-understood, cheap to operate, and easy to split later along boundaries you have already enforced in code.

Splitting into services is an answer to a specific goal — independent deploy cadence for a team that is genuinely blocked, or a workload whose scaling profile is nothing like the rest. Both are real. Neither is the same as wanting the diagram. If a strategy proposes services and cannot name which goal the split serves, the honest bullet is a modular monolith with the boundary enforced by a build check.

The same discipline applies to every fashionable move: event sourcing, a second language on the backend, a service mesh, a bespoke internal platform. Each is right sometimes. Each costs an operational surface a small team pays for daily, and that cost belongs in the bullet next to the benefit.

Identity, payments, email, search, feature flags, observability, inference. A current system buys most of its undifferentiated capability, so the strategy's real content is which capabilities you build because they are the product and which you rent because they are not.

Write each purchase as a strategy move, not a procurement footnote, because each one is an availability ceiling and a per-unit cost you do not control — the arithmetic the context concern makes explicit. Buying is usually correct and rarely free.

The line to hold is around the thing that differentiates you. Renting your identity provider is sound; renting the model of your own domain is how you end up with a product shaped by someone else's data model and a migration nobody will fund.

Cost per tenant, per request, per active user — not the monthly bill. The bill tells you what happened; the unit figure tells you whether the shape you chose survives ten times the volume, which is the question the strategy is answering.

Two moves that meet the same functional need can differ by an order of magnitude at scale, and the difference is usually invisible at current volume. That is precisely when the strategy is written, so put the projected unit cost in the bullet rather than discovering it in a finance review eighteen months later.

Commitments and reserved capacity are dated facts, so they belong in constraints with an expiry, not in strategy. Strategy names the shape; constraints record the contract that made one shape cheaper for the next two years.

Greenfield strategies are the exception. Most of the time the moves apply to something already in production with users on it, which means every bullet needs the path as well as the destination: what runs in parallel, how the data moves, what the rollback is, and how you know the new path is correct before the old one is deleted.

Strangler-fig migration, dual writes with reconciliation, shadow reads compared for a fortnight. These are the mechanics, and a strategy that names an end state without one of them is a wish. The migration is also where the cost lands: running both paths for a quarter is the real price of the move, and it is the number that gets left out.

Two of the classic reasons to avoid a move were the cost of writing it and the cost of the boilerplate around it. Both have collapsed. What has not collapsed is the cost of understanding it at 3am, reviewing a change to it, migrating it, or explaining its failure to a customer.

So the strategy's centre of gravity shifts toward reversibility, isolation and verifiability. A move that halves the code and doubles the blast radius is now a worse trade than it looked three years ago; a move that adds code but keeps a failure inside one boundary is a better one. Optimise for the expensive part, and the expensive part is no longer typing.

This is also the honest answer to premature abstraction. It has always been tempting and it is now cheap to produce and just as expensive to own — an agent will build the generalised version enthusiastically, and the ownership cost falls on whoever is on call.

One HTTP client, one error shape, one persistence pattern, one way to schedule background work. That used to be a style guide; when a large share of code is generated it becomes architecture, because generation multiplies whatever variety it finds and each variant is a separate thing to operate.

Say it in the strategy and enforce it with a guardrail. "One way to do a thing, and the way lives at this path" is a bullet an import-boundary test or a lint rule can defend, which is the difference between a stated preference and a property of the system.

The cost of skipping it is not ugly code. It is four retry implementations with three different backoff behaviours, discovered during an incident caused by the one that had none.

Strategy has no spine.yaml key, deliberately — it is derived from decisions and quality goals, and inventing a machine layer for a derived view would be two sources of truth for one fact. What it has instead is brevity, and brevity is what survives a context window.

That matters because an agent with no statement of shape does not stop and ask. It pattern-matches to the most common architecture on the internet, which is a plausible average of a million tutorials and is not your system. Five bullets naming the shape, the defaults and the deviations is the cheapest correction available, and it fits in every session rather than being fetched when somebody remembers.

An agent is also good at the review that keeps this page honest: finding moves with no cited decision, decisions that contradict a bullet, and deferrals whose trigger has quietly been met.

The economics of "we'll add it later" have changed. Later is now cheap enough that an agent, asked for a small feature, will happily add the multi-tenant abstraction, the plugin system or the second cache you had decided not to have yet — and the diff will look competent.

So the deferral list stops being documentation and becomes a constraint on generation: these are the things we chose not to have, and here is the signal that would change that. Written that way, it is checkable in review; written as an omission, it is an invitation.

Give each deferral an owner and a trigger you can actually observe — a contract term, a load figure, a support-ticket pattern. A trigger phrased as "when it becomes a problem" is not a trigger; it is the same silence with better manners.