Microservice architecture has become a widely adopted approach for building scalable and maintainable systems. However, one of the most complex decisions when implementing this architecture is defining the scope of each microservice. Should you split functionalities into separate services or keep them together? The answer lies in balancing what I call _integrators_ and _disintegrators_—factors that either encourage combining functionalities or suggest splitting them into distinct services.

In this blog post, I’ll break down how these integrators and disintegrators guide the microservice design process and help define the right boundaries.

## **The Role of Integrators and Disintegrators**

In this context:

- **Integrators**: Factors that suggest combining functionalities within a single service.

- **Disintegrators**: Factors that push you to separate functionalities into distinct services.

Balancing these factors ensures your microservices are scalable, maintainable, and resilient.

## **Disintegrators: When to Split Functionalities**

1. **Code Volatility** If certain functionalities change frequently and independently from others, it’s better to split them. This allows you to update one service without affecting others, reducing the risk of deploying changes.

2. **Access Control** Services with different access control requirements should be separated. Trying to enforce varying levels of security and permissions within a single service can lead to complex and error-prone configurations.

3. **Cohesion** High cohesion is critical for service maintainability. If different functionalities within a service are not tightly related in purpose, splitting them reduces unnecessary complexity and improves service focus.

4. **Fault Tolerance** If a failure in one part of a system should not cause the entire service to fail, separating functionalities ensures better fault isolation. This approach improves overall resilience by containing failures within specific services.

5. **Scalability** Different components often have unique scaling requirements. Splitting services based on how they scale individually allows for more efficient resource utilization and better performance.

## **Integrators: When to Combine Functionalities**

1. **Data Dependencies** When multiple functionalities rely on the same data model or require tight data consistency, combining them within a single service avoids complex distributed transactions and synchronization issues. Domain driven design helps to determie right bounded context of your domain, which is a huge factor in the microservice scope definition.

2. **Workflow** Complex workflows that involve multiple tightly coupled steps are better managed within the same service. Splitting them across multiple services could lead to unnecessary inter-service communication and increased latency.

3. **Database Transactions** Distributed transactions across services are often a red flag in microservice design. If certain operations require atomic transactions, it’s generally more efficient to keep them within a single service, simplifying both design and implementation.

## **Conclusion**

Designing microservices is a balancing act. While disintegrators encourage splitting functionalities for better autonomy and flexibility, integrators highlight cases where combining functionalities can simplify data consistency, workflows, and transactions.

There are no one-size-fits-all rules for defining microservice scope, but by analyzing the integrators and disintegrators relevant to your domain, you can design services that are well-scoped and aligned with both business needs and technical goals.

Ultimately, the key lies in understanding your domain deeply and making pragmatic decisions about service boundaries. With the right balance, you can create a microservice architecture that is both flexible and sustainable.

Defining Microservice Scope - Integrators and Disintegrators

Coupling types listed from the weakest:

- Domain coupling - different modules shares the same domain

- Temporal coupling - coupling in time, when one module assumes, that antoher will be available at time the communication

- Pass-through coupling - module takes data structure and passes to another module

- Common coupling - modules write to the same database

- Content coupling - modules modifies the same database table

_Microservices, 2nd edition by Sam Newman_

_Fundamentals of Software Architecture: An Engineering Approach 1st Edition by Mark Richards (Author), Neal Ford_