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.