Architecture Decision Records
One decision, its context, alternatives and consequences, kept immutable.
5 to work through
-
intermediate Multiple choice
A 60-engineer platform organisation of nine teams is introducing decision records and leadership asks what a healthy annual volume looks like so they can tell whether the practice is working. Roughly how many records should they expect per year?
2 min answer -
intermediate
A team writes decision records diligently and nobody reads them. What is wrong with the practice rather than the format?
2 min answer -
intermediate
An interviewer asks you to pick an architectural decision your team made in the last year and write its decision record on the whiteboard, then hands you a fact partway through that would have changed the choice. What is being assessed, and how should you work through it?
3 min answer -
intermediate
Review this decision log. It holds 140 records over four years in the repository. 31 are marked superseded and 9 of those name no successor. Two records state conflicting positions on the same message bus and both read "accepted". The template has a Consequences heading that is empty in 96 records. A new engineer asked what the current position on async messaging is and spent half a day finding out. What would you change, what would you remove, and what would you leave alone?
3 min answer -
intermediate
Your team writes ADRs and nobody reads them. What is wrong with them?
2 min answer
3 terms in this topic
Decision Context Capture
Recording the situation, constraints and forces that made a decision reasonable, so that later readers can judge whether it still applies.
practiceDecision Granularity
How much a single decision record covers, chosen so a later change can replace exactly the part that has become wrong instead of invalidating a docum…
metricDecision Half-Life
The observed time it takes for half a set of architecture decision records to be superseded, read as a diagnosis of how the records are written rathe…
Neighbouring topics
Architecture Decision-Making
General material on making and recording architectural decisions.
Reversibility
One-way and two-way doors, and buying optionality deliberately.
Build vs Buy
Differentiation, five-year TCO, and the exit cost of each option.
Monolith vs Microservices
A team-topology decision far more often than a technology one.
SQL vs NoSQL
Decided by access patterns and query flexibility, not by data volume.
Sync vs Async
Whether the caller's outcome depends on the callee's response.
Strong vs Eventual Consistency
A per-operation decision, resolved by what a stale read would cost.
Managed vs Self-Managed
Trading control and unit cost against operational attention.
Serverless vs Containers
Spiky and event-driven versus sustained throughput.
Single vs Multi-Region
Driven by RTO, RPO and residency rather than by ambition.
Centralised vs Distributed
Shared platform leverage against team autonomy.
Performance vs Cost
Buying latency, and knowing what the last millisecond is worth.
Reliability vs Complexity
Mechanisms that add availability and add failure modes.
Security vs Usability
Varying control by the value of the action rather than uniformly.
Delivery vs Maintainability
Fast in the cheap places, careful in the expensive ones.
Deciding Under Uncertainty
Bounding the downside and buying information cheaply.
Trade-off Analysis Methods
ATAM, scenarios, and naming the points where qualities conflict.
Technology Selection
Evaluating options against drivers rather than against enthusiasm.
Decision Practice
Thresholds, review, supersession and keeping the log alive.