Introduction
Microservices have become really popular over the last few years because many large tech companies started to use them. But are they a solution for most problems? Should you switch to microservices?
Most common scenarios
Below are some common flags that you should be paying attention that can drive the decision.
Logical segregation
If different parts of your system represent independent domains (like payments and notifications), the boundaries are already there, and splitting them into separate services should feel natural.
Team size
If in your company the devs are constantly dealing with merge conflicts, or changes in one module frequently break another, maybe this is a scenario that a microservice architecture could help. Or maybe not, It could be also an organization issue.
Uneven Scalability
If a module in an application needs to be scaled 100 times larger than the rest, maybe it should be isolated, turning it into a microservice.
Independent deployments
If a part of the system needs to be deployed in a different frequency, without deploying everything else, separating it into its own service may reduce risk.
Different tech stack
If you have an AI module, maybe using python is more effective than Java, which may be the default language in your project. So this AI module could become a microservice.
Summary
The scenarios that require a microservice architecture are way less common than many people think. To prevent overengineering always start with a monolith, and only migrate if you feel the operational need.
A distributed system introduces a lot of complexity, such as network failures, deploy management and observability. Make sure those trade-offs are worth it before adopting microservices.
Top comments (0)