Service decomposition strategies in Microservices - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is service decomposition in microservices?

Service decomposition is the process of breaking down a large application into smaller, independent services that each handle a specific business capability.

beginner

Name one common strategy for decomposing services based on business capabilities.

Decomposing services by business capabilities means creating services that align with distinct business functions, like 'Order Management' or 'User Profile'.

intermediate

What does the 'Decompose by Subdomain' strategy mean?

It means splitting services according to different subdomains identified in the business domain, often using Domain-Driven Design concepts to isolate bounded contexts.

intermediate

Why is it important to avoid tight coupling between decomposed services?

Avoiding tight coupling ensures services can be developed, deployed, and scaled independently, improving flexibility and fault isolation.

advanced

What is a drawback of decomposing services too granularly?

Too fine-grained services can lead to increased complexity in communication, higher latency, and more operational overhead.

Which of the following is NOT a common service decomposition strategy?

A Decompose by user interface layout

B Decompose by database schema

C Decompose by subdomain

D Decompose by business capability

Decomposing by user interface layout is not a recommended strategy because UI concerns should not dictate service boundaries.

What is the main goal of service decomposition?

A To split an application into independent services with clear responsibilities

B To create a single monolithic application

C To increase database joins

D To reduce the number of services

Service decomposition aims to create independent services that focus on specific business functions.

Which design approach helps identify subdomains for decomposition?

A Test-Driven Development

B Waterfall Model

C Domain-Driven Design

D Continuous Integration

Domain-Driven Design helps identify bounded contexts and subdomains for service boundaries.

What is a risk of having tightly coupled microservices?

A Easier independent deployment

B Better scalability

C Improved fault isolation

D Harder to change one service without affecting others

Tight coupling makes it difficult to change or deploy services independently.

Which factor should NOT primarily influence service boundaries?

A Team organization

B UI design

C Database technology

D Business capabilities

UI design should not dictate service boundaries; services should focus on business logic.

Explain the main strategies used to decompose a monolithic application into microservices.

Think about how to split responsibilities clearly and keep services independent.

Describe the advantages and disadvantages of decomposing services too finely.

Consider what happens when services become very small.

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