Service decomposition strategies in Microservices - Deep Dive

Overview - Service decomposition strategies

What is it?

Service decomposition strategies are ways to break a large software system into smaller, independent parts called services. Each service handles a specific part of the system's work. This helps teams build, update, and scale parts of the system without affecting everything else. It is a key idea in microservices architecture.

Why it matters

Without service decomposition, software systems become large and tangled, making them hard to change or fix. Changes in one part can break others, slowing down development and causing outages. Decomposing services lets teams work faster, scale better, and keep systems more reliable. It also helps match software parts to real business needs.

Where it fits

Before learning service decomposition, you should understand basic software architecture and the idea of microservices. After this, you can learn about service communication, data management in microservices, and deployment strategies. It fits early in the journey of designing scalable, maintainable systems.

Mental Model

Core Idea

Breaking a big system into smaller, focused services lets each part work independently and fit business needs better.

Think of it like...

Imagine a big restaurant kitchen where one chef tries to cook everything alone. Service decomposition is like dividing the kitchen into stations: one for salads, one for grills, one for desserts. Each station focuses on its task, making the whole kitchen faster and less chaotic.

┌───────────────┐
│   Big System  │
└──────┬────────┘
       │
       ▼
┌───────────────┐   ┌───────────────┐   ┌───────────────┐
│ Service A     │   │ Service B     │   │ Service C     │
│ (Salads)     │   │ (Grills)     │   │ (Desserts)   │
└───────────────┘   └───────────────┘   └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding monolithic systems

Concept: Learn what a monolithic system is and why it can be problematic.

A monolithic system is built as one large block where all parts are tightly connected. Imagine a single app where the user interface, business logic, and data access are all mixed together. This makes it hard to change one part without affecting others and can slow down development.

Result

You see why large systems become hard to maintain and scale when built as one piece.

Understanding the limits of monoliths shows why breaking systems into smaller parts is necessary.

2

Foundation

What is service decomposition?

Concept: Introduce the idea of splitting a system into smaller services.

Service decomposition means dividing a big system into smaller, independent services. Each service handles a specific function or business capability. This separation allows teams to develop, deploy, and scale services independently.

Result

You grasp the basic idea of microservices and why decomposition is key.

Knowing decomposition is the foundation for building flexible and scalable systems.

3

Intermediate

Decomposition by business capability

🤔Before reading on: do you think services should be split by technical layers or by business functions? Commit to your answer.

Concept: Learn to split services based on distinct business functions or capabilities.

This strategy divides the system by what the business does, like orders, payments, or user management. Each service owns its data and logic for that function. This aligns software with business teams and goals, making changes clearer and faster.

Result

You understand how business-driven decomposition improves team autonomy and clarity.

Understanding business capabilities as boundaries helps avoid tangled code and unclear responsibilities.

4

Intermediate

Decomposition by subdomain (Domain-Driven Design)

🤔Before reading on: do you think all parts of a business are equally complex and should be treated the same? Commit to your answer.

Concept: Use domain-driven design to split services by subdomains within the business.

Domain-Driven Design (DDD) breaks a business into subdomains like core, supporting, and generic. Each subdomain can become a service. This helps focus on the most important parts and manage complexity by isolating different business areas.

Result

You see how DDD guides decomposition to match business complexity and priorities.

Knowing subdomains lets you design services that reflect real business structure and reduce confusion.

5

Intermediate

Decomposition by technical layers

Concept: Split services by technical roles like UI, API, or database access.

This approach divides the system into layers such as front-end, back-end, and data services. While simpler, it can create tight coupling between layers and reduce service independence. It is less common in microservices but useful in some cases.

Result

You recognize the tradeoffs of technical-layer decomposition.

Understanding this helps avoid common pitfalls of layering that reduce microservice benefits.

6

Advanced

Decomposition by transaction boundaries

🤔Before reading on: do you think services should share databases freely or keep their own data? Commit to your answer.

Concept: Split services so each handles its own transactions and data consistency.

Each service owns its data and manages transactions internally. This avoids complex distributed transactions and reduces dependencies. Services communicate asynchronously to keep data consistent across the system.

Result

You learn how transaction boundaries improve reliability and scalability.

Knowing transaction boundaries prevents data conflicts and complex coordination in distributed systems.

7

Expert

Balancing granularity and coupling

🤔Before reading on: do you think smaller services are always better? Commit to your answer.

Concept: Learn how to find the right size for services to avoid too many tiny or too few large ones.

Very small services increase communication overhead and complexity. Very large services reduce independence. Experts balance service size to optimize team productivity, system performance, and maintainability. This requires understanding business needs and technical constraints.

Result

You appreciate the nuanced tradeoffs in service sizing.

Understanding granularity balance is key to building practical, scalable microservices.

Under the Hood

Service decomposition works by defining clear boundaries around business capabilities or data ownership. Each service runs independently, with its own database and logic. Services communicate over networks using APIs or messaging. This isolation reduces dependencies and allows independent deployment and scaling.

Why designed this way?

Originally, software was built as monoliths for simplicity. As systems grew, monoliths became hard to maintain and scale. Decomposition was designed to align software structure with business domains and team organization. It trades some complexity in communication for better modularity and agility.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Service A     │◄──────│ API Gateway   │──────►│ Service B     │
│ (Own DB)      │       └───────────────┘       │ (Own DB)      │
└───────────────┘                               └───────────────┘
        ▲                                              ▲
        │                                              │
   Independent                                    Independent
   Deployment                                     Deployment

Myth Busters - 4 Common Misconceptions

Quick: Do you think splitting services always improves system performance? Commit yes or no.

Common Belief: Splitting services always makes the system faster and more scalable.

Reality: Too many small services increase communication overhead and latency, which can slow down the system.

Why it matters: Ignoring communication costs can cause degraded performance and harder troubleshooting.

Quick: Do you think all services should share the same database? Commit yes or no.

Common Belief: All services can share one database to keep data consistent easily.

Reality: Sharing databases tightly couples services, reducing independence and making deployments risky.

Why it matters: This can cause cascading failures and blocks independent scaling or updates.

Quick: Do you think technical layers are the best way to split services? Commit yes or no.

Common Belief: Splitting by technical layers like UI and backend is the best decomposition.

Reality: This creates dependencies between services and does not align with business needs well.

Why it matters: It leads to tight coupling and slows down team autonomy and delivery.

Quick: Do you think smaller services always mean simpler systems? Commit yes or no.

Common Belief: Smaller services always make the system simpler to understand and maintain.

Reality: Too many tiny services increase complexity in communication, deployment, and monitoring.

Why it matters: This can overwhelm teams and cause operational challenges.

Expert Zone

1

Service boundaries should consider organizational team structure to reduce coordination overhead.

2

Decomposition must balance between business domain alignment and technical feasibility to avoid over-engineering.

3

Event-driven communication patterns often emerge naturally from decomposition by transaction boundaries.

When NOT to use

Avoid microservice decomposition when the system is small or simple; a monolith may be easier to develop and maintain. Also, if the team lacks experience with distributed systems, decomposition can add unnecessary complexity. Alternatives include modular monoliths or service-oriented architecture (SOA).

Production Patterns

In production, decomposition often follows business domains with APIs managed by an API gateway. Teams use asynchronous messaging for data consistency and implement service meshes for communication control. Continuous integration and deployment pipelines automate independent service releases.

Connections

Domain-Driven Design

Service decomposition builds on DDD's subdomain boundaries to define service scopes.

Understanding DDD helps create services that reflect real business domains, improving clarity and maintainability.

Event-Driven Architecture

Decomposed services often communicate asynchronously using events.

Knowing event-driven patterns helps manage data consistency and decoupling between services.

Organizational Design

Service boundaries often mirror team structures to reduce communication overhead.

Recognizing Conway's Law shows how software architecture and team organization influence each other.

Common Pitfalls

#1 Creating too many tiny services that communicate excessively.

Wrong approach:

Splitting every small function into its own service without considering communication costs.

Correct approach:

Group related functions into a service that balances size and independence to reduce overhead.

Root cause:

Misunderstanding that smaller is always better leads to excessive complexity.

#2 Sharing a single database across multiple services.

Wrong approach:

Multiple services directly accessing the same database tables.

Correct approach:

Each service owns its database and exposes data via APIs or events.

Root cause:

Lack of understanding of service independence and data ownership.

#3 Decomposing services by technical layers instead of business capabilities.

Wrong approach:

One service for UI, one for business logic, one for data access.

Correct approach:

Decompose by business functions like orders, payments, or users.

Root cause:

Confusing technical separation with business domain separation.

Key Takeaways

Service decomposition breaks a large system into smaller, independent services aligned with business needs.

Choosing the right decomposition strategy impacts team autonomy, system scalability, and maintainability.

Avoid too fine-grained services to reduce communication overhead and operational complexity.

Each service should own its data to maintain independence and simplify deployments.

Understanding business domains and transaction boundaries guides effective service design.