The TLDR version of this post is this: don’t use microservice architecture if you have a small team, below is why.

Microservice isn’t meant for a single team, conway’s law tells us that: organizations ship their communication structure, and hence microservices comes as a result of having multiple teams working on the subdomains in an independent manner, independent teams who owns a service end to end and control the release cycle and abstract the internal details of the service as a public interface will yield a microservice architecture, the opposite is quite hard to achieve.

microservices is there in the first place to allow multiple teams to work on decoupled subdomains of the original issue independently, breaking away from the need to sync across a large number of members of one team, but when you have few developers developing your app, you don’t have the kind of issues microservice architecture solves, your small team now has to develop distributed services, deploy and manage each of them, atop of solving your domain issue your software is trying to, which in itself would be a complex one (that’s why Eric Evans had the subtitle of “tackling complexity at the heart of software design” for his book). so what would have been a single monolith app that’s easier to deploy, is now decomposed into multiple microservices that your team needs to develop, deploy and monitor, and keep in mind complexity increases if you want to employ eventing/massaging between those services.

I would even argue that adopting microservices architecture for a small team impacts productivity negatively, having your app in one codebase and a monolith app allows you to reuse your code, implement cross-cutting concerns that span across the full app, things like error handling, logging corners …etc. those are the sort of benefits that allows you to easily achieve more by reusing what you have already written before.

Another thing that’s gets stacked against monolith apps is scalability, microservices are advertised as scalable, but nothing is preventing the scalability of a one monolith application, microservices allows independent scaling where one microservice could see more traffic, and you can scale it to match that traffic, but there is nothing preventing you from scaling a monolith app as well, while each component/route on a monolith could receive different traffic load and you need to scale the whole app to match the load this route is seeing.

And I see teams going for a microservice architecture from the get-go on the assumption that their app user base will grow and they are future proofing their app to be scalable, there is a subconscious idea here that needing to re-architect your app is a failure or a lack of oversight, but I would argue it’s the opposite, needing to re-architecture your app to meet new scaling requirements is a sign of success, it means you developed an app that’s users want to use, your userbase is growing, and you have your app success on your back to expand your team and start adopting a microservice architecture.