Think twice before you microsize!

Not every functionality from an application needs to be a microservice! After all, the prefix "micro" suggests something small. But how small a microservice should be? You might think: let's follow the SRP with microservices also. But this can be subjective!

?

If you have these issues when sizing a microservice, such as how granular your services should be, then you're not alone. Initially, ensuring a solid understanding of the following two terms is essential:

?

1. Modularity: shows if the components of a system can be separated and recombined.

2. Granularity: shows the size and scope of a single service

?

As previously mentioned, the most issues with distributed systems are not related to modularity, but with granularity. Determining the right level of granularity is one of the issues faced by the developers and architects.

To address this issue, we have 2 concepts:

·??????? Granularity disintegrators:? are aspects that influence the decision to break down services further or to keep them larger. These factors often pose challenges that necessitate careful consideration of service granularity.

·??????? Granularity integrators: are aspects that encourage combining functionalities or keeping services larger (or not breaking them apart in the first place) to maintain efficiency and cohesiveness. They act as a counterbalance to disintegrators, promoting integration where it benefits the system.

?

Now that you have some factors to help you make better decisions on when to break apart a service into smaller parts or when to leave it as it is, let's dive in. I'll start with granularity integrators.

?

Database transactions as a granularity integrator?

The database transactions integrator highlights the challenges of maintaining data consistency across multiple granular services. In a microservices architecture each service has its own database. When a business process is handled by multiple services, ensuring data consistency and that the transactions are completed successfully in an atomic way becomes complex. To handle this complexity, you will need to use compensating transactions or distributed transaction patterns, such as Saga pattern, to handle failures and rollback scenarios. By consolidating functionalities that often engage in the same transactions, you can diminish the complexity and overhead linked with distributed transactions, enhancing the overall system's reliability and performance.

?

Workflow and choreography as granularity integrator?

Workflow in microservices architecture is a defined set of steps or activities that are executed to achieve a specific goal. This involves orchestrating multiple microservices and you might use an orchestration service, that is responsible for determining which service needs to do which tasks in what order. Choreography, on the other hand, takes a decentralized approach: each service knows its role in the workflow and initiates interaction with other services when needed. This method relies on services being aware of the sequence of interactions but reduces the need for a central managing entity. Workflow and choreography as granularity integrators advocate for balanced approach to service design, when the services are neither too small, nor a monolith.

?

Designing a system that effectively handles these considerations takes careful planning and understanding. Use this guidance as your light as you fine-tune your strategy, making sure your microservices are not only effective now but also strong and flexible for what comes next.