Architecture decision records (ADR) in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Purpose of Architecture Decision Records (ADR)

What is the main purpose of using Architecture Decision Records (ADR) in a microservices system?

A To replace the need for unit testing in microservices development

B To automatically generate code for microservices based on architecture diagrams

C To monitor the performance of microservices in real-time

D To document important architectural decisions and their context for future reference

💡 Hint

Think about why teams keep records of decisions they make about system design.

ADRs are used to record architectural decisions, their reasons, and consequences. This helps teams understand why certain choices were made and supports future maintenance and evolution.

❓ Architecture

intermediate

Key components of an ADR document

Which of the following is NOT typically included in an Architecture Decision Record?

A The context and problem the decision addresses

B The decision made and its status

C The detailed source code implementation of the decision

D The consequences and trade-offs of the decision

💡 Hint

ADRs focus on decisions, not code details.

ADRs describe decisions, their context, and consequences but do not include detailed source code. Code is maintained separately.

❓ scaling

advanced

Scaling ADRs in a large microservices organization

In a large organization with many microservices teams, what is the best approach to keep Architecture Decision Records (ADRs) effective and manageable?

A Use a shared ADR template and encourage teams to link related ADRs across repositories

B Allow each team to maintain their own ADRs locally without any coordination

C Avoid writing ADRs to save time and rely on verbal communication instead

D Centralize all ADRs in a single repository and require all teams to submit decisions there

💡 Hint

Think about balancing consistency and team autonomy.

Using a shared template ensures consistency, while linking ADRs across repositories allows teams to maintain autonomy and trace decisions relevant to their services.

❓ tradeoff

advanced

Trade-offs in ADR granularity

What is a key trade-off when deciding how detailed each Architecture Decision Record should be?

A Less detail reduces clarity but makes ADRs quicker to create and maintain

B Less detail means ADRs can replace all other documentation

C More detail makes ADRs easier to write but harder to understand

D More detail always improves team communication without downsides

💡 Hint

Consider the balance between clarity and effort.

Highly detailed ADRs provide clarity but take more time to write and maintain. Less detail speeds up writing but may reduce understanding.

❓ component

expert

Request flow trace involving ADR usage

Consider a microservices system where a new architectural decision is made to switch from synchronous REST calls to asynchronous messaging between services. Which component in the request flow is most directly impacted by this ADR?

A The API Gateway that routes incoming requests to services

B The message broker or event bus handling asynchronous communication

C The database storing user data

D The client application making requests

💡 Hint

Think about what changes when communication switches from direct calls to messaging.

Switching to asynchronous messaging means the message broker or event bus becomes a key component in the request flow, handling communication between services.

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