Writing the Consequences Section of an ADR

Option B is correct. The Consequences section records all types of outcomes — positive (what we gain), negative (what we sacrifice or accept), and neutral (changes that are neither good nor bad, just different). It is distinct from the rationale (which explains why) and the context (which describes the problem). A complete Consequences section includes: (1) trade-offs accepted, (2) new constraints introduced, (3) follow-up decisions or work triggered. Example: "Positive: teams can deploy independently. Negative: distributed tracing becomes required. Neutral: each service now owns its own database. Follow-up: ADR-012 needed for inter-service communication protocol."

Option C is correct. A well-written trade-off entry names: (1) the nature of the trade-off (eventual consistency), (2) where it applies (across service boundaries), and (3) a quantified or scoped impact (stale data for up to 500ms post-write). This is actionable — developers know exactly what they need to handle. Option A is a positive framing, not a trade-off. Option B is too vague ("more complex" is not actionable). Option D is non-committal filler. Every negative consequence should be specific enough that a developer reading it knows what defensive code, monitoring, or documentation is needed as a result.

Option B is correct. A positive consequence entry should name: (1) the specific capability gained (full ACID compliance), (2) what it enables or prevents (ensures integrity across multi-step transactions), and (3) what constraint or complexity it removes (no need for compensating transactions). This is useful because it explains why the positive matters — not just that it exists. Option A ("well-known database") describes popularity, not a technical consequence. Option C ("team knows it") describes familiarity, not a technical outcome. Option D is wishful thinking, not a specific consequence. Positive consequences justify why the decision is correct; make them precise and outcome-focused.

Option C is correct. A follow-up entry should: (1) reference the specific follow-up artefact needed (ADR-019), (2) state exactly what that artefact must address (retry + DLQ strategy), (3) explain why it is needed (this decision introduces new failure modes). This creates a traceable chain of decisions. ADRs often cascade — one decision creates scope for others. Capturing this in Consequences ensures nothing falls through the cracks. Option A is too vague. Option B ("think about security") is a task disguised as a consequence. Option D ("discuss in next sprint") is a meeting note, not an architectural consequence. Follow-up entries should be actionable commitments, not reminders.

"Accepting this decision has the following consequences:" is the standard ADR Consequences section header. It uses the MADR (Markdown Architectural Decision Records) and Michael Nygard ADR conventions. The phrasing "accepting this decision" is deliberate — it signals that the consequences flow from the decision being recorded, not from the situation that preceded it. Option A is too casual and subjective. Option C is hopeful, not analytical. Option D introduces unnecessary hedging ("subject to change") — if the consequences change, a new ADR should be written. The Consequences section should be written as a confident record of known outcomes at the time of the decision.