Architecture decision records (ADR) in Microservices - Deep Dive

Overview - Architecture decision records (ADR)

What is it?

Architecture decision records (ADRs) are simple documents that capture important decisions made about a software system's design. They explain what was decided, why, and what alternatives were considered. ADRs help teams remember and communicate the reasons behind architectural choices over time.

Why it matters

Without ADRs, teams often forget why certain design choices were made, leading to repeated debates, inconsistent implementations, and difficulty onboarding new members. ADRs provide a clear history that improves communication, reduces confusion, and helps maintain system quality as it evolves.

Where it fits

Learners should first understand basic software architecture and microservices concepts. After ADRs, they can explore advanced topics like architectural governance, continuous delivery, and system evolution management.

Mental Model

Core Idea

An ADR is a simple, written snapshot of a key architectural decision, explaining what was chosen, why, and what else was considered.

Think of it like...

An ADR is like a travel journal entry that records why you chose a particular route, what other paths you thought about, and what you expect along the way, so you or others can understand the journey later.

┌───────────────────────────────┐
│       Architecture Decision    │
│           Record (ADR)         │
├──────────────┬────────────────┤
│ What         │ The chosen design
│ Why          │ Reasons for choice
│ Alternatives │ Other options
│ Consequences │ Effects of choice
└──────────────┴────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding architectural decisions

Concept: Introduce what architectural decisions are and why they matter in software systems.

Architectural decisions are choices about the structure and behavior of a software system. For example, deciding to use microservices or a monolith, choosing a database type, or selecting communication protocols. These decisions shape how the system works and evolves.

Result

Learners recognize that architecture involves many important choices that affect the system's success.

Understanding that architecture is a series of decisions helps learners see why documenting these choices is valuable.

2

Foundation

What is an Architecture Decision Record?

Concept: Define ADR as a lightweight document capturing a single architectural decision.

An ADR records the decision title, context, the decision itself, alternatives considered, and consequences. It is usually short and focused on one decision to keep things clear and manageable.

Result

Learners know the basic structure and purpose of an ADR.

Knowing that ADRs are simple and focused encourages teams to adopt them without fear of heavy documentation.

3

Intermediate

Writing effective ADRs

🤔Before reading on: do you think ADRs should include only the final decision or also rejected options? Commit to your answer.

Concept: Teach how to write clear, useful ADRs including alternatives and reasoning.

Effective ADRs include: 1) Decision title, 2) Context explaining the problem, 3) The chosen option, 4) Alternatives considered with pros and cons, 5) Consequences of the decision. This helps future readers understand the full picture.

Result

Learners can create ADRs that communicate decisions clearly and help future maintenance.

Including alternatives and consequences prevents repeated debates and helps teams learn from past choices.

4

Intermediate

Organizing ADRs in a project

🤔Before reading on: do you think ADRs belong in code repositories, separate docs, or emails? Commit to your answer.

Concept: Explain best practices for storing and managing ADRs alongside code.

ADRs are best stored in the project's version control system, often in a dedicated folder like /docs/adr/. This keeps them close to the code, versioned, and easy to update. Using simple markdown files is common.

Result

Learners understand how to integrate ADRs into their workflow for easy access and updates.

Keeping ADRs with code ensures decisions evolve with the system and remain discoverable.

5

Intermediate

Using ADRs in microservices architecture

Concept: Show how ADRs help manage complexity in microservices by documenting service boundaries and communication choices.

Microservices involve many independent services interacting. ADRs document decisions like service responsibilities, API protocols, data ownership, and deployment strategies. This clarity helps teams coordinate and avoid conflicts.

Result

Learners see ADRs as tools to handle microservices complexity and team coordination.

Documenting microservices decisions prevents misunderstandings and supports scalable system growth.

6

Advanced

Evolving ADRs over time

🤔Before reading on: do you think ADRs are static or should they be updated as systems change? Commit to your answer.

Concept: Teach how to maintain ADRs as architecture evolves, including deprecating or superseding decisions.

ADRs should be living documents. When a decision changes, create a new ADR referencing the old one as superseded. This preserves history and shows architectural evolution clearly.

Result

Learners can manage ADRs to reflect system changes without losing context.

Maintaining ADR history helps teams understand why changes happened and supports better future decisions.

7

Expert

Integrating ADRs with automated workflows

🤔Before reading on: do you think ADRs can be part of automated CI/CD pipelines? Commit to your answer.

Concept: Explore advanced practices of linking ADRs with code reviews, deployment, and monitoring.

Some teams automate ADR checks during pull requests to ensure new decisions are documented. ADRs can trigger alerts if architecture drifts from decisions. Integrating ADRs with tools improves governance and quality.

Result

Learners discover how ADRs become active parts of development and operations.

Automating ADR management enforces discipline and reduces architectural decay in complex systems.

Under the Hood

ADRs work by capturing decisions as discrete, versioned text files stored alongside code. Each ADR contains structured sections that explain the decision context, options, and consequences. This structure allows teams to trace architectural history and rationale easily. Version control tracks changes, enabling collaboration and evolution over time.

Why designed this way?

ADRs were designed to be lightweight and simple to encourage adoption. Heavy documentation slows teams down, so ADRs focus on essential information. Storing ADRs with code ensures decisions stay relevant and accessible. Alternatives like large architecture documents were too rigid and quickly outdated.

┌───────────────┐        ┌───────────────┐
│ Developer     │        │ Version       │
│ makes decision│───────▶│ Control       │
└───────────────┘        │ System        │
                         └─────┬─────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │ ADR file in repo     │
                    │ - Title             │
                    │ - Context           │
                    │ - Decision          │
                    │ - Alternatives      │
                    │ - Consequences      │
                    └─────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think ADRs are only needed for big decisions? Commit yes or no.

Common Belief: ADRs are only useful for major architectural choices.

Reality: ADRs are valuable for any significant decision that affects system design, big or small.

Why it matters: Ignoring smaller decisions leads to gaps in understanding and inconsistent implementations.

Quick: Do you think ADRs replace all other documentation? Commit yes or no.

Common Belief: ADRs replace the need for other documentation like diagrams or user guides.

Reality: ADRs complement other documentation by focusing on decision rationale, not detailed design or usage.

Why it matters: Relying only on ADRs can leave teams without necessary operational or design details.

Quick: Do you think ADRs must be formal and lengthy? Commit yes or no.

Common Belief: ADRs have to be formal, detailed documents to be useful.

Reality: ADRs are meant to be brief and clear to encourage frequent use and updates.

Why it matters: Overly formal ADRs discourage teams from writing or maintaining them.

Quick: Do you think ADRs are static once written? Commit yes or no.

Common Belief: Once an ADR is written, it should never be changed.

Reality: ADRs evolve; new ADRs can supersede old ones to reflect changes in architecture.

Why it matters: Treating ADRs as static leads to outdated decisions and confusion.

Expert Zone

1

Some ADRs capture not only decisions but also the decision-making process, including stakeholders and meeting notes, which helps in audits and accountability.

2

The granularity of ADRs varies; too coarse loses detail, too fine creates noise. Finding the right balance is key and depends on team culture.

3

In microservices, ADRs often link to service-specific repositories, requiring cross-referencing to understand system-wide architecture.

When NOT to use

ADRs are less useful for trivial or very short-lived decisions that do not impact architecture. For fast experiments or prototypes, lightweight notes or tickets may suffice. Also, in very small teams with informal communication, ADR overhead might be unnecessary.

Production Patterns

In production, ADRs are integrated into code review processes to ensure decisions are documented before merging. Teams use ADR templates and automation to enforce consistency. ADRs also serve as inputs for architectural governance boards and help during onboarding and audits.

Connections

Version Control Systems

ADRs are stored and versioned using version control systems like Git.

Understanding version control helps grasp how ADRs evolve and stay synchronized with code changes.

Decision Theory

ADRs formalize decision-making by documenting options, criteria, and consequences.

Knowing decision theory principles clarifies why documenting alternatives and trade-offs improves architectural quality.

Legal Contracts

Like contracts, ADRs record agreements and commitments between parties (developers, teams).

Seeing ADRs as agreements highlights their role in accountability and reducing misunderstandings.

Common Pitfalls

#1 Writing ADRs after decisions are implemented.

Wrong approach:

Implement feature X, then write an ADR describing what was done.

Correct approach:

Write the ADR before implementation to guide development and get team alignment.

Root cause:

Misunderstanding ADRs as documentation rather than planning tools.

#2 Making ADRs too long and detailed.

Wrong approach:

Writing multi-page documents with excessive technical details and history.

Correct approach:

Keep ADRs concise, focusing on key points: decision, context, alternatives, consequences.

Root cause:

Confusing ADRs with full design documents or specifications.

#3 Not updating ADRs when architecture changes.

Wrong approach:

Leaving old ADRs unchanged even after decisions are reversed or replaced.

Correct approach:

Create new ADRs that supersede old ones and reference them clearly.

Root cause:

Treating ADRs as static records rather than living documents.

Key Takeaways

Architecture decision records (ADRs) capture key design choices clearly and simply to preserve decision history.

Writing ADRs before implementation aligns teams and prevents repeated debates and confusion.

Storing ADRs with code in version control keeps decisions accessible and up to date.

ADRs evolve over time; new records can supersede old ones to reflect architectural changes.

Integrating ADRs into workflows and automation improves architectural governance and system quality.

Practice

1. What is the main purpose of an Architecture Decision Record (ADR) in microservices projects?

easy

A. To document important architecture decisions and their reasons

B. To write detailed code for each microservice

C. To track bugs and issues in the system

D. To monitor server performance metrics

Solution

1. Step 1: Understand the role of ADRs

   ADRs are used to record key architecture decisions and why they were made.

2. Step 2: Differentiate ADRs from other documents

   ADRs are not for code, bugs, or performance monitoring but for decision documentation.

3. Final Answer:

   To document important architecture decisions and their reasons -> Option A

4. Quick Check:

   Purpose of ADR = Document decisions [OK]

Hint: ADRs capture decisions, not code or bugs [OK]

Common Mistakes:

• Confusing ADRs with bug tracking
• Thinking ADRs are code documentation
• Assuming ADRs monitor system metrics

2. Which of the following is the correct basic structure of an ADR document?

easy

A. Title, Status, Context, Decision, Consequences

B. Title, Code, Tests, Deployment, Logs

C. Summary, Bugs, Fixes, Performance, Metrics

D. Introduction, User Stories, UI Design, API Endpoints

Solution

1. Step 1: Recall ADR standard sections

   ADRs typically include Title, Status, Context, Decision, and Consequences.

2. Step 2: Eliminate unrelated structures

   Options with code, bugs, or UI design are unrelated to ADR format.

3. Final Answer:

   Title, Status, Context, Decision, Consequences -> Option A

4. Quick Check:

   ADR structure = Title, Status, Context, Decision, Consequences [OK]

Hint: Look for Context and Consequences in ADR structure [OK]

Common Mistakes:

• Mixing ADR with test or deployment docs
• Confusing ADR with bug reports
• Including UI design in ADR

3. Given this ADR excerpt:

Title: Use REST for service communication
Status: Accepted
Context: Need simple, stateless communication
Decision: Use REST over HTTP
Consequences: Easier integration but higher latency

What is the main consequence documented here?

medium

A. REST requires stateful connections for speed

B. REST causes stateless communication to fail

C. REST reduces integration complexity and latency

D. REST leads to easier integration but higher latency

Solution

1. Step 1: Read the Consequences section carefully

   The consequence states "Easier integration but higher latency".

2. Step 2: Match the consequence with options

   REST leads to easier integration but higher latency matches exactly; others contradict the text.

3. Final Answer:

   REST leads to easier integration but higher latency -> Option D

4. Quick Check:

   Consequence = Easier integration, higher latency [OK]

Hint: Focus on Consequences section for effects [OK]

Common Mistakes:

• Ignoring the 'higher latency' part
• Assuming REST reduces latency
• Confusing stateless with stateful

4. You find an ADR with this status:

Status: Deprecated

What does this status indicate about the decision?

medium

A. The decision is newly proposed and under review

B. The decision is no longer recommended or used

C. The decision is currently active and enforced

D. The decision has been accepted but not implemented yet

Solution

1. Step 1: Understand ADR status meanings

   "Deprecated" means the decision is outdated and should not be used.

2. Step 2: Compare with other statuses

   New proposals are "Proposed", active ones "Accepted", so deprecated means no longer recommended.

3. Final Answer:

   The decision is no longer recommended or used -> Option B

4. Quick Check:

   Status 'Deprecated' = Not recommended [OK]

Hint: Deprecated means outdated, avoid using [OK]

Common Mistakes:

• Confusing deprecated with accepted
• Thinking deprecated means new proposal
• Assuming deprecated means pending

5. Your team must decide between using REST or gRPC for microservice communication. You want to document this choice clearly for future reference. Which is the best way to use an ADR in this situation?

hard

A. Write code samples for both REST and gRPC without explanation

B. Skip documentation and decide by majority vote only

C. Write an ADR with Context explaining needs, Decision stating REST or gRPC, and Consequences of each choice

D. Create a bug report to track this decision

Solution

1. Step 1: Identify ADR purpose for decision documentation

   ADRs should explain context, decision, and consequences clearly.

2. Step 2: Evaluate options for documenting architecture choices

   Only Write an ADR with Context explaining needs, Decision stating REST or gRPC, and Consequences of each choice uses ADR properly; others ignore documentation or misuse formats.

3. Final Answer:

   Write an ADR with Context explaining needs, Decision stating REST or gRPC, and Consequences of each choice -> Option C

4. Quick Check:

   Use ADR to document decision and consequences [OK]

Hint: Use ADR to record context, decision, and consequences [OK]

Common Mistakes:

• Skipping documentation
• Confusing ADR with bug reports
• Only writing code without explanation