How Small Should Microservices Be?

One of the most frequent questions within the implementation of microservices architecture is about size and granularity of microservices. How small should microservices be? Should a piece of software be split into multiple microservices or built as a single one? Trying to answer these questions, I came to some criteria to help me to make a decision.

Rather than focusing on pizza-size teams or the single responsibility principle, it’s better to stay pragmatic and focus on possible advantages and drawbacks of the design decision and challenge why a particular piece of software needs to be split. To do this, we need to model a part of the system that we want to build as multiple microservices candidates: define bounded contexts, main entities, and service capabilities around these entities. With a rough picture, we can think about benefits and drawbacks of such design from multiple perspectives.

Isolation of Changes Perspective

Do you expect changes in requirements of one candidate to be independent of another? By isolating the risk of changes to break something that wasn’t changed is reduced. Usually, changes in one bounded context change independently of others. The organization of microservices around business capabilities is a key success factor here. Since microservices provide a high level of isolation, they can help isolate changes.

Isolation of Static Services

Do we isolate services that don’t change frequently? While some requirements change frequently, others might change so rarely that we can treat microservice as static. Examples of such static microservices could be services responsible for sending emails or SMS, document or image format conversion, localization or translation, etc. In most of the system, such functionality changes rarely while main business features might change quickly. By isolating static functionality, we reduce the risk of breaking it and increase the necessity of testing.

Isolation of Business Critical Services

Do we isolate business-critical operations from the less critical? In some systems, we can divide functions that are vital and stop the system from being useful when they are unavailable. Such functionality for a web shop could be purchasing functionality while the recommendations system or wishlist are not that critical. Business-critical operations must be as much isolated as possible from non-critical functionalities. This will minimize the probability of affecting business-critical operations by troubles with non-critical functionality. Separate isolated microservice for pure critical functionality is usually a good idea.

Cohesion Perspective

Is one of the candidates fully independent in runtime from another? Mutual dependencies are a sign of high cohesion and bad candidates for different microservices.

Team Setup Perspective

Do you expect those candidates to be implemented by different development teams? The microservices approach is especially good to isolate work of one team from another.

Technology Perspective

Can the candidates be implemented more effectively with different technologies? Microservices make possible polyglot implementations where different programming languages and frameworks might be used.

Data Consistency and Transaction Boundaries Perspective

Can you accept eventual consistency between candidates? If not, this might be an issue since strong consistency in distributed systems is a complex topic. Are there any atomic business operation across the candidates? This might be not trivial to achieve with separate services.

Non-Functional Requirements Perspective

Are performance and availability requirements for those candidates different? It’s easier to deal with small and simple performance models where critical operations are isolated and implemented in the most optimal way. On the other hand, each remote call is a latency and risk of failure. The availability of the the business process relying on multiple microservices by default is lower than if the process relies just on one microservice.

Security Perspective

Is one of the candidates processing high-sensitive data while another is not? Least common mechanism security principle says that it’s safer to make processing of highly sensitive date separate from other data.

Give priority to questions that matter for your system. If the nswer is “yes” to most of them, then it might be a good idea to continue with those microservices candidates. Reiterating over each candidate and thinking about if any further segregated microservices would make sense will result in pragmatic decisions on microservices granularity.