Architecture decision records

Architecture decision records

A decision made in a meeting evaporates the moment the room clears, and six months later someone reverses it without knowing what it cost the last time. An ADR is the durable answer to "why is it built this way": one file, written once, that a future maintainer can trust more than anyone's memory.

Method

1. One decision per record, numbered and immutable. Name files docs/adr/0007-use-postgres-for-billing.md. The number never changes and the file is append-only after acceptance. A record that mixes two decisions cannot be superseded cleanly when only one of them ages out.
2. Write the context as forces, not narrative. State the constraints, requirements, and pressures in play: throughput targets, team skills, existing contracts, deadlines. The reader must feel the pressure that made the decision reasonable at the time, even if it looks wrong later.
3. State the decision in the active voice. "We will store billing events in Postgres and stream them to the warehouse nightly." Not "Postgres seems like a good option." A decision hedged into a suggestion is not a decision.
4. Record consequences honestly, both signs. List what gets easier and what gets harder: the new operational burden, the capability you gave up, the follow-on work this forces. An ADR with only upsides is marketing.
5. Track status through a fixed lifecycle. Proposed, accepted, deprecated, superseded. When a later ADR overrides this one, mark it "Superseded by ADR-0021" and link both directions. Never edit the decision of an accepted record: write a new one that replaces it.
6. Keep the record next to the code it governs. Store ADRs in the repo, not a wiki that drifts. Tools like adr-tools or the MADR template scaffold the file and the index; a link from the affected module's README closes the loop.

Litmus tests

• Can a new engineer read the record and defend the decision to a skeptic without asking anyone what really happened?
• Does every accepted ADR name at least one consequence the team dislikes?
• When a decision is reversed, can you find the superseding record from the old one in a single click?

Boundaries

Record decisions that are expensive to reverse or affect more than one team: routine, two-way-door choices belong in the commit message, not an ADR. Adopt your organization's existing RFC or ADR template where one is in use rather than inventing a parallel format.