The proper size of a microservice
In this article I will talk about which I consider being the best size for a microservice.
Category
Related tags
microservices, proper size of a microservice, ddd, Domain-Driven Design, bounded context
Introduction
Many people wonder which is the proper size of a microservice is or to be more specific, what micro means. You can make a microservice of a single function, and many microservices are as big as monoliths. So, which is the best size for a microservice?
Too small is not cohesive
If your microservices are very small, for example, if you only have one single function, then chances are your microservice is gonna be too little to be cohesive enough. Remember that cohesive means that the unit of code has everything related at hand, so the whole needed domain is together.
If it's too small, you are going to depend on other microservices, and is very likely that you also need to depend on synchronous communication, which is not the best possible approach.
If it's too small, you'll need to have many integration tests, as most of the features are very spread across the whole microservices architecture.
Too big is a monolith
Obviously, if your microservice is very big then you have a monolith, and you lose all the advantages of microservices. It will be hard to test -and slow to run tests-, scalability will be low, and the deployment will take so long.
If your microservice is too big, you'll probably have several subdomains and bounded contexts inside, which makes it more difficult to reason about.
We can discuss what micro means, but by any means "too big" is a good definition.
Using bounded contexts as the proper size for a microservice
If you follow Domain-Driven Design practices, you should be dividing your domain into the different subdomains that shape it. And you've probably learned about bounded contexts.
Using a bounded context as the proper size for a microservice has the following advantages:
- It represents, by definition, only a part of the domain, so is not as big as a monolith which represents the whole domain.
- As you've bounded the domain, you have all the needed stuff together, so is cohesive.
- As it's bounded by definition, you can use this bound as the interface for APIs and messages. You need an adapter to cross boundaries, and in a microservice, this adapter is the network.
Conclusion
This is not a rule the theory enforces in general, as there is a lot of debate around the size of microservices. But is something that helped me in the past -and today- to define what is the proper size of a microservice. And it worked very well, so I hope it can be useful for you too.