Service decomposition strategies in Microservices - System Design Guide

Problem Statement

When a monolithic application grows, it becomes hard to maintain, slow to deploy, and difficult to scale. Teams face delays because changes in one part affect the whole system, causing frequent conflicts and outages.

Solution

Service decomposition breaks the monolith into smaller, independent services. Each service owns a specific business capability and can be developed, deployed, and scaled separately. This reduces dependencies and improves agility.

Architecture

User Client

→API Gateway

↓

↓

This diagram shows a user client sending requests to an API Gateway, which routes them to multiple independent services (A, B, C), each handling a specific business function.

Trade-offs

✓ Pros

→

Improves scalability by allowing independent scaling of services based on demand.

→

Enables faster development cycles as teams can work on separate services without conflicts.

→

Increases fault isolation; failure in one service does not crash the entire system.

→

Supports technology diversity; different services can use different tech stacks.

✗ Cons

→

Introduces complexity in managing inter-service communication and data consistency.

→

Requires robust monitoring and logging to trace issues across services.

→

Deployment and testing become more complex due to distributed nature.

When the application has grown beyond a few thousand lines of code and multiple teams work on it. Also, when scaling parts of the system independently is needed, typically at 1000+ daily active users or complex business domains.

For small applications with simple logic and low traffic (under 1000 daily users), where the overhead of managing multiple services outweighs benefits.

Real World Examples

Netflix

Decomposed their monolith into microservices to independently scale streaming, recommendations, and user management, improving reliability and deployment speed.

Amazon

Split their e-commerce platform into services like catalog, orders, and payments to allow teams to innovate and deploy independently.

Uber

Used service decomposition to separate rider, driver, and trip management services, enabling rapid feature development and scaling.

Alternatives

Modular Monolith

Keeps the application as a single deployable unit but organizes code into modules with clear boundaries.

Use when: When you want better code organization without the operational complexity of microservices.

Shared Database Decomposition

Services share a common database schema but have separate codebases, reducing data duplication but increasing coupling.

Use when: When data consistency is critical and eventual consistency is not acceptable.

Event-Driven Decomposition

Services communicate asynchronously via events, decoupling them more than direct API calls.

Use when: When you need high scalability and loose coupling with eventual consistency.

Summary

Service decomposition breaks a large application into smaller, independent services based on business capabilities.

This approach improves scalability, fault isolation, and team autonomy but adds complexity in communication and operations.

Choosing the right decomposition strategy depends on application size, team structure, and business needs.

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