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

Microservices can communicate synchronously and asynchronously. These are the main group of communication means for microservices. Lest dig in to unwrap, what does it mean.

**Synchronous communication** means is sending a request to another microservice and waiting for a response. Opening a connection and waiting for a response. This is the most simple communication option for microservices. It is easy to implement and use, but it has its tradeoffs. The tradeoff is that your microservice is blocked by another microservice response. This type of communication creates [temporal coupling](https://www.buzzchart.info/post/coupling-and-cohesion). The implementation of synchronous communication can be either HTTP REST call calls or RPC.

_When to use?_

- Used when the user or client of the microservice expects an 'immediate' response. For example calculate book price based on all gathered parameters.

- You are implementing [distributed transaction](https://www.buzzchart.info/post/distributed-transactions-in-microservices) and want your application state to be as [consistent](https://www.buzzchart.info/post/cap-theorem) as possible.

_Pros and cons_

✔️ simple to implement.

✔️ simple to understand (observe) the system.

❌ creates [temporal coupling](https://www.buzzchart.info/post/coupling-and-cohesion) in the application.

❌ can cause performance issues in case target microservice is slow or overloaded.

❌ opens a lot of connections for big traffic. In case microservice throughput is limited, then it can cause a major performance issues.

**Asynchronous communication** is a communication style, when you are not getting the response right away. In some cases you are not getting a response at all. Three groups of communication patterns can be utilized for asynchronous programming.

- Request-Response communication - can be implemented as sync and also async with the queue based message brokers. Two queues are present, for requests and for responses. The sender will get the response from the queue marked with the correlation id.

- Event-driven communication - is communication pattern where sender does not wait for the response at all. It emits the event via the message broker. Other microservices can consume the event, if they are subscribed to it. This pattern ✔️ decouples microservices and letting them communicate via strictly defined interfaces. This pattern implies the ❌ complexity in understanding the application as a whole. The [observability tools and practices](https://www.buzzchart.info/post/observability) can help this problem.

- Common data communication - is a pattern when all microservices are writing to the same data store. It can be filesystem or database. Then other microservices can read from this data storage. This pattern creates a ❌ [common coupling](https://www.buzzchart.info/post/coupling-and-cohesion) (writing to the same data store) between microservices, but it is ✔️ simple to implement and maintain.

_Pros and Cons_

✔️ decouples microservices, letting them evolve independently

❌ increases complexity in the application

_When to use?_

- Use it when you need to decouple microservices. This communication style allows to do it completely.

- Use it for a long lived tasks. These tasks cannot provide immediate response. For example you need to check the number of books in the warehouse, before sending and marking in the system that it is sent. This type of task cannot be done synchronously.

_Microservices, 2nd edition by Sam Newman_

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

Note: The content in this article is a summary/interpretation inspired by them. Proper attribution is given to the respective authors.

Microservice Communication Patterns

You want to scale your microservice, when the load exceeds the available resources. Resources can be CPU, RAM, database throughput, workers pool. I will describe two common patterns how to scale your microservices.

### **Vertical Scaling**

"Vertical scaling" is a simple option, which can be considered as a go to, when performance issues arises. With this pattern you need to update your hardware, using more RAM or CPU. If your service is spinning on a virtual machine, then it is a matter of configuration.

- ✔️ simple implementation

- ❌ has physical limitations

- ❌ can become very expensive

### **Horizontal duplication Scaling**

With "Horizontal duplication" pattern you need to copy your microservices (and possibly database) and control load via load balancer or message broker. This is a big advantage of microservices architecture, to have possibility to scale the "hot-spot" microservice. Where in the monolith you will copy the whole application.

If you need to scale your database horizontally, one of the options is to make "read replica" which will be used only for reads. Writes will be sent to the primary database.

- ✔️ cheaper to scale

- ❌ complex implementation

- ❌ the database need to be synced

Microservices Scaling patterns

Domain driven design (DDD) is a methodology for designing software with a focus on the domain. DDD is one of the main practices used in the microservices development. I'll cover 3 main concepts of the DDD:

- Ubiquitous Language - use the same language/terms in the code and in the business. This allows programmers to talk to the business people without misinterpretation.

- Aggregate - Related objects, that form a consistency boundary and are treated as a single unit. For example in the "Customer" domain, "Address" is an aggregate.

> An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes. Each aggregate has a root and a boundary. The boundary defines what is inside the aggregate. The root is a single, specific ENTITY contained in the aggregate.

_Domain Driven Design, Eric Evans_

- Bounded Context - a logical and physical boundary around a coherent and consistent domain or subdomain

What if you already have a domain and want to slice it to migrate from the monolith to the microservices, for example? You can do this using these patterns:

- Volatility - split by the performance sensitive parts

- Data - split by usage or restrictions on the data

- Technology - split by a technology stack

- Organizational - align with the company organizational structure

_Microservices, 2nd edition by Sam Newman_

Domain Driven Design

CAP abbreviation means: Consistency, Availability and Partitioning tolerance. Theorem states, that distributed data store can have two of three guarantees:

- Consistency - every read from the store will receive most recent write result.

- Availability - application is highly available. Almost all requests will be returned with a response.

- Partitioning tolerance - ability to distribute / partition data store.

In microservice architecture, which is distributed by its nature, you cannot have option CA.

- You can choose from the PA and data will be eventually consistent.

- Or you can have CP, but not always an available service to respond. Handling distributed data stores syncing can take time. This means you need to use locks and persistent queues to support data sync.



CAP theorem

Transactions in microservices are not possible, because of the distributed nature of microservices. Though you can implement compensation mechanisms to handle failures in multiple microservices calls for one business action. There are patterns to handle this situation:

- 2 Phase commit - pattern to check, wether microservice is able to write with this data before actually making the 'writing'.

- Choreography-based saga - Multiple 'write' calls, where microservices are called in the chain. Each subsequent call of microservice knows how to rollback or compensate the 'write' call. This type of saga is easier to implement. It is More decoupled, than orchestration based saga. However, it is harder to grasp the whole business process.

- Orchestration-based saga - This pattern implies, that you have an "orchestrator" microservice. It will calls different microservices and knows how to compensate fail 'write' call. The business process is easier to understand from the saga implementation. However, it introduces domain coupling on different microservice domains.

! what is worth mentioning: Do not implement sagas. Saga introduces complexity to your microservices (both book authors have the same opinion).

! ACID is not supported in the microservices

_Microservices, 2nd edition by Sam Newman_

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

Distributed "Transactions" in Microservices

- Page based decomposition - each microservice has ts own dedicated page. This pattern enables vertical slice of an application. ✔️ You can deploy your UI and backend for a vertical slice of an application independently from other microservices. ❌ Has limited capabilities creating complex UI.

- Widget based decomposition - each widget can communicate only with it's own microservice. ✔️ You can deploy your UI and backend for a vertical slice of an application independently from other microservices. ❌ Adds complexity in managing communication between widgets.

- Central Aggregating gateway - gateway (with transformation, filtering, aggregation) as a single entrypoint to the microservices. Good fit when you have a separate UI teams and microservices teams. Creates horizontal layers of an application (n-tier architecture). ✔️ Simplifies UI development. ❌ Creates coupling on the gateway side.

- Backend For Frontend (aka BFF) - same as CAG per client type. This pattern fits, when you have multiple client types (web, ios, android, 3rd party API). ✔️ It solves the general purpose API problem and enables teams to develop independently. ❌ It creates coupling on the gateway layer, and introduces code duplication.

_patterns by Sam Newman from the book Microservices 2nd edition_