06-Sep-2022 by Damian Maclennan

How micro should a microservice be?

How micro should a Microservice be? How micro is too micro? These are questions as old as the term microservice.

The answer is that is less about size and more a question of function. A service should own a self contained domain or business process and contain all the logic and data to do its job.

The common anti-pattern is known as the “entity service pattern”, or sometimes the “service per aggregate root”.

These services often contain no real logic outside of storing and querying some data, usually a single entity, sometimes as little as a single table. If your service is basically an HTTP wrapper around a repository pattern you’re probably suffering from this.

The problem is that to do anything useful, you’ll probably need to get data from multiple services, and those services might need to fetch data from another service. You’ve basically reimplemented table joins across a synchronous chain of HTTP calls.

This can affect your ability to deploy, your performance, your resilience, and you’ll find yourself with the same set of classes in multiple services as each services just has to “know” too much about the others.

Instead, if you model your services around business processes, and store enough information locally for each service to fulfil that process, your services will be faster, more resilient, and easier to maintain.