How to Size a Microservice

The size of a microservice is an important factor to consider before we start transitioning from a monolith to microservices architecture. We should also think through the plan to isolate the microservice from rest of the system.

From the name itself we understand that the size should be micro. But, our primary goal should not be to make services as small as possible. Instead, our goal should be to isolate the identified bounded context and keep it small.

The following factors need to be considered for the high-level isolation of microservices.

  1. Requirement changes: Changes in the requirements of one microservice should be independent of other microservices. In such cases, we will isolate/split our software into smaller services in such a way that, if there are any requirement changes in one service, they will be independent of another microservice.
  2. Change Frequency: We should try to isolate functionalities that are rarely changed from others that may demand frequent changes.
  3. Team Changes: We should also consider isolating our microservices in such a way that one team should not be dependent on other teams to complete their tasks.
  4. Technology Changes: Technology use needs to be isolated vertically within each module. A module should not be dependent on a technology or component from another module. We should strictly isolate the modules developed in different technologies or stacks, or look at moving them to a common platform as a last resort.

While the above factors help us size the microservices, one should also consider the following features to make it a good service.

  1. Standard Data Formats: Services should follow standardized data formats while exchanging services or systems with other components. The most popular data formats used in the .NET stack are XML and JSON.
  2. Standard communication protocol: Services should obey standard communication formats, such as SOAP and REST.
  3. Loose coupling: When services are loosely coupled, we don’t have to worry about changes. Changes in one service will not impact other services.

You might be interested in the following courses:

Course Category: Microsoft Technologies

Back to: Microservices with C#, .NET Core and Azure > The Transition And Building