beginner 2 min answer

When is an architectural decision worth an ADR, and what makes an ADR useful two years later?

adrdocumentationgovernance
Show the full answer Hide the answer

What the interviewer is testing

Whether you document decisions as a habit, and whether you know that most documentation fails because it records the wrong thing.

When to write one

The threshold is cost of reversal, not size. Write an ADR when:

  • Undoing the decision would take more than a few days.
  • It affects more than one team, or constrains someone else's choices.
  • You considered a reasonable alternative and rejected it — that reasoning is exactly what gets lost.
  • You are deliberately departing from a standard, in which case the ADR is also the deviation record.
  • Someone will predictably ask "why is it like this?"

Do not write one for a library choice you could swap in an afternoon, or for something with no alternative considered. An ADR log padded with trivia stops being read, which costs you the ones that matter.

What makes it useful later

Context, written honestly and in the present tense of the decision. What was true at the time — team size, deadline, existing systems, what was unknown. Two years later this is the part that explains a decision that now looks wrong: it was correct given three engineers and a hard date.

The alternatives, with why each was rejected. Without this, the next person re-evaluates the same options from scratch and often picks the one you already ruled out for a reason nobody wrote down.

The consequences, especially the negative ones. "We accept eventual consistency between these two services and therefore need a reconciliation job" is the sentence that saves an incident. An ADR with only benefits is a decision that was not really made.

Immutability. Never edit an accepted ADR. Supersede it with a new one that references the old. The value of the log is that it shows what was believed at each point, which a continuously edited document destroys.

Proximity to the code. In the repository, in version control, reviewed in the same pull request as the change. An ADR in a wiki nobody opens is not documentation.

The format

One page. Title, status, date, context, decision, alternatives, consequences. Longer than a page means it is either two decisions or a design document.

What a strong answer adds

Noting that ADRs are how architecture survives staff turnover, which is the actual problem being solved. Also that the discipline of writing one frequently improves the decision — being made to articulate the rejected alternatives surfaces the option you had not properly considered.