To be able to answer that we should start from a different question: what kind of problems we believe smaller/independently deployable codebases solve better than a monolithic codebase with a single deployment unit?

I think there are two main problems microservices can help solving:

  • runtime scaling
  • iteration speed

Depending on the type of the business domain we may hit one of these before the other but they often come hand-in-hand. These two problems are the the ones that push us to split up a monolith. They are also the ones that help us in deciding when is good time to further split any of our microservices.

In this post I will focus only on the iteration speed problem.

Basically what iteration speed means is how many developers can we have working on the codebase without seeing significant slowdown. If we believe that a team is most effective when it works towards a single goal at a time (single piece flow) then it should be fine for a whole team working together on a single microservice. This gives us good starting point in answering what is a good size for a microservice.

However, it is quite likely that over time there are many different things that the team is responsible for. It does not make sense to bundle all of them together into a TeamMicroservice. That's where we should apply common sense and keep things that are independent separated from each other. Aside from that I think we should not worry too much about accidentally building another monolith. As long as the team is small enough it should be able to keep code in single codebase modular enough so that there are really no good reason to physically split modules at least from iteration speed perspective.

When thinking how big/small should our microservices be then it is good to think what is the business goal we try to achieve. Through this we are able to make much better decision than blindly following another cargo cult and spinning off hundreds of microservices just because some very successful companies are doing that.

Hero image - a crocodile made by my son Jarek