Service decomposition strategies in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Identifying the primary principle of domain-driven design (DDD) in service decomposition

Which of the following best describes the main idea behind using domain-driven design (DDD) for decomposing microservices?

A Decompose services based on technical layers like UI, business logic, and database

B Create one service per database table to simplify data access

C Split services according to business capabilities and bounded contexts

D Group all functionalities into a single service to reduce communication overhead

💡 Hint

Think about how business domains guide service boundaries.

Domain-driven design focuses on dividing systems by business domains and bounded contexts, which helps create services aligned with real-world business capabilities.

❓ Architecture

intermediate

Choosing the best decomposition strategy for a retail platform

A retail platform wants to decompose its monolith into microservices. Which decomposition strategy would best isolate the payment processing functionality?

A Decompose by technical layers: UI service, payment service, and database service

B Decompose by business capabilities: separate payment service from order and inventory services

C Decompose by database tables: one service per table including payment table service

D Decompose by user roles: one service for customers, one for admins, one for payment

💡 Hint

Consider which approach isolates business functions clearly.

Decomposing by business capabilities isolates payment processing as its own service, which improves maintainability and scalability.

❓ scaling

advanced

Scaling challenges with database-per-service pattern

What is a common scaling challenge when using the database-per-service pattern in microservices?

A Data consistency becomes difficult due to distributed transactions across multiple databases

B All services must use the same database technology, limiting flexibility

C Services cannot scale independently because they share a single database

D Scaling is automatic and requires no additional design considerations

💡 Hint

Think about how data consistency is managed across services.

Using separate databases per service leads to challenges in maintaining data consistency because distributed transactions are complex and often avoided.

❓ tradeoff

advanced

Tradeoff of fine-grained vs coarse-grained service decomposition

What is a key tradeoff when choosing fine-grained service decomposition over coarse-grained in microservices?

A Fine-grained services increase the number of network calls and operational overhead

B Fine-grained services reduce network calls but increase code complexity

C Coarse-grained services always improve fault isolation compared to fine-grained

D Coarse-grained services eliminate the need for service discovery mechanisms

💡 Hint

Consider how service size affects communication and management.

Fine-grained services lead to more network calls and higher operational complexity, while coarse-grained services reduce calls but may be less flexible.

❓ estimation

expert

Estimating service count from bounded contexts

A system has 5 bounded contexts identified by domain experts. Each bounded context is expected to be decomposed into 3 microservices on average. What is the estimated total number of microservices after decomposition?

A 5

B 8

C 20

D 15

💡 Hint

Multiply the number of bounded contexts by the average services per context.

Multiplying 5 bounded contexts by 3 services each results in 15 total microservices.

Practice

1. Which of the following best describes the main goal of service decomposition in microservices?

easy

A. Combining multiple services into one large service

B. Creating a single database for all services

C. Removing all dependencies between services

D. Breaking a large system into smaller, manageable services

Solution

1. Step 1: Understand the purpose of decomposition

   Service decomposition aims to split a big system into smaller parts for easier management.

2. Step 2: Evaluate options against this goal

   Only Breaking a large system into smaller, manageable services describes breaking down a system into smaller services, which matches the goal.

3. Final Answer:

   Breaking a large system into smaller, manageable services -> Option D

4. Quick Check:

   Service decomposition = smaller services [OK]

Hint: Decomposition means splitting big into small [OK]

Common Mistakes:

• Thinking decomposition means merging services
• Assuming it removes all dependencies
• Confusing decomposition with database design

2. Which of the following is a common strategy to decompose microservices?

easy

A. By server hardware

B. By business capability

C. By programming language

D. By network protocol

Solution

1. Step 1: Recall common decomposition strategies

   Common strategies include decomposing by business capability, subdomain, or data entity.

2. Step 2: Match options to known strategies

   Only By business capability matches a recognized strategy; others are unrelated to service design.

3. Final Answer:

   By business capability -> Option B

4. Quick Check:

   Decompose by business function = C [OK]

Hint: Decompose by what the business does [OK]

Common Mistakes:

• Choosing technical infrastructure as decomposition criteria
• Confusing programming language with service boundaries
• Thinking network protocols define services

3. Given a system with services decomposed by subdomain, which of the following is a likely benefit?

medium

A. Single point of failure for all features

B. Reduced number of services to manage

C. Improved team autonomy and focused development

D. Elimination of all data duplication

Solution

1. Step 1: Understand subdomain decomposition

   Decomposing by subdomain groups services by business areas, enabling teams to work independently.

2. Step 2: Analyze benefits

   This approach improves team autonomy and focus, but does not reduce services or eliminate data duplication fully.

3. Final Answer:

   Improved team autonomy and focused development -> Option C

4. Quick Check:

   Subdomain decomposition = team autonomy [OK]

Hint: Subdomain splits by business area, helps teams [OK]

Common Mistakes:

• Assuming fewer services means better decomposition
• Expecting zero data duplication always
• Thinking it creates single failure points

4. A team decomposed services by data entity but faces tight coupling between services. What is the likely cause?

medium

A. Services share too much data and depend on each other

B. Services are deployed on different servers

C. Services use different programming languages

D. Services have separate databases

Solution

1. Step 1: Identify cause of tight coupling

   Tight coupling often happens when services share data heavily and depend on each other.

2. Step 2: Evaluate options

   Only Services share too much data and depend on each other explains tight coupling due to shared data and dependencies; others are unrelated.

3. Final Answer:

   Services share too much data and depend on each other -> Option A

4. Quick Check:

   Tight coupling = shared data dependency [OK]

Hint: Tight coupling means services depend on shared data [OK]

Common Mistakes:

• Blaming deployment location for coupling
• Thinking different languages cause tight coupling
• Assuming separate databases cause coupling

5. You are designing a microservices system for an online store. Which decomposition strategy best supports independent team ownership and scalability?

hard

A. Decompose by business capability like order management, payment, and inventory

B. Decompose by database tables to minimize data duplication

C. Decompose by programming language to use best tools per service

D. Decompose by server location to reduce network latency

Solution

1. Step 1: Identify goals for decomposition

   Independent team ownership and scalability require clear service boundaries aligned with business functions.

2. Step 2: Match strategies to goals

   Decomposing by business capability groups related functions, enabling teams to own services and scale independently.

3. Step 3: Evaluate other options

   Decomposing by tables or languages does not align with team ownership; server location affects latency, not ownership.

4. Final Answer:

   Decompose by business capability like order management, payment, and inventory -> Option A

5. Quick Check:

   Business capability decomposition = team ownership + scalability [OK]

Hint: Group by business functions for team and scale benefits [OK]

Common Mistakes:

• Choosing database tables over business functions
• Thinking programming language defines service boundaries
• Focusing on server location instead of service design