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

Session state is a concept in the software applications to share a user-specific data across multiple actions or requests during a single user session. User session can contain:

- User authentication information

- User preferences

- Form data, navigation history, shopping cart contents or any other application state, that user do not want to lose

- Temporary data

- Security tokens

## **Client Session State**

It is a practice to store session to the browser cookies or localStorage.

- ✅ Reducer server load. Do not need to share the data between the requests. Reduces memory footprint.

- ✅ Scalability. When server is stateless you can scale it horizontally.

- ✅ Simplified Session management. Frontend developer controls session timeouts and session data.

- ❌ Security risk. Sensitive data may be expose to the XSS attacks. Sensitive daa must be encrypted.

- ❌ Data integrity. User can modify session data. All data and server requests must be validated.

- ❌ Cross device usage. Session data is available only per one device. You can sync session data across devices, but it comes with a cost.

- ❌ Privacy issues. Regulations such as GDPR require explicit consent from user. It adds additional complexity and impacts the user experience.

## **Server Session State**

It is a practice to store session on the server side.

- ✅ Security. Sensitive data is kept on the server, which is harder for an attacker to manipulate data.

- ✅ Data Integrity. Server can validate and manage data without relying on untrusted client.

- ✅ When session is kept in memory, it is fast to resolve and update the session. Also you do not need to serialize and deserialize the session data, if you are keeping it in memory.

- ❌ Scalability. If you want to scale the server in case of high load, this can cost more, than to scale a stateless server. More complex scalability patterns must be applied depending on where session data is kept.

- ❌ If session is kept in memory, that Availability becomes very important. If server is down, user will lose his session.

## **Database Session State**

- ✅ Persistance. The user session data will survive server crashes and restarts.

- ✅ Scalability. It allows data to be stored and accessed in centralized manner. This is beneficial for a scaled instances of the same application.

- ✅ Security. Databases can provide out of the box features for encryption, access control and audit trails.

- ✅ Data Integrity. Data is managed centralized.

- ❌ Performance overhead . Retrieving data from the database costs more, that from the in memory object.

- ❌ Increased complexity. Maintain session data in the database, requires additional database configuration, connection management and abstractions resolving this data.

- ❌ Dependency. Database becomes a critical dependency for an application to operate. Database is made a SPOF (Single Point of Failure). Database performance becomes critical for an system availability.

Session State

ACID (Atomicity, Consistency, Isolation, Durability) in IT is a properties of a business (or database) transactions, that guarantees the reliability and data integrity of the transaction.

- **Atomicity** - transaction as one unit. If one operation of transaction fails, the transaction is failed

- **Isolation** - concurrent transactions are shielded form the "effects" of other transactions

- **Consistency** - from one consistent database state to another to another consistent database state

- **Durability** - guarantees that once a transaction is committed, changes will survive any system failures