“When should you switch to microservices?”
![](https://habrastorage.org/getpro/habr/upload_files/998/f75/a34/998f75a34573e19a46924cdff0b23350.jpg)
We already figured out in the previous article when microservices are not needed, now let's look at the opposite situation.
It may sound a bit idealistic, but imagine that you have a fast-growing project, constantly needing new employees, needing to scale. This is where the question of changing the architecture comes up when you feel that the monolithic one is no longer working for you.
It’s difficult to objectively evaluate your project, but you can start with a question with a bit of impostor syndrome: “Has my project grown to microservices? How do I know if I need to switch to them?”
Let's start with the fact that you won't be able to switch to them quickly, most likely, at first you will unload the most loaded module, for example, the one that receives requests. In the middle of the path, your architecture will resemble mini-services until each module is taken out separately and connected to each other. Let me remind you that if you don't “make friends” with them, all your work will be meaningless.
Small modules are easier to control, several points of failure provide greater reliability, this is the main advantage of microservice architecture, that's why everyone wants it. For example, you have a large online store, more than a thousand orders per minute, it is scary to store this structure in a monolith, if one element is disconnected, the entire store will stop working until the problem is solved, which means a big loss of profit and loyalty to the business. With microservices, everything will be less bloody, if a bug is found in the “registration” module, then new users simply will not be able to log in, but will be able to select a product and place an order.
![](https://habrastorage.org/getpro/habr/upload_files/ad3/db8/f21/ad3db8f213cb6c8905ef69edf61ca8fc.jpg)
But here it is important to evaluate the load on the site, how well everything is configured in the architecture depends on how long it takes everything to load, whether it slows down. If you distribute the load correctly, assign at least three specialists to each module, you can maintain the service even with the processing of a large amount of data.
It is also easy to update a microservice, you don't need to rewrite everything, you add/remove/update only the required module, the work of the rest does not suffer at this time. The main thing is not to forget to correctly connect everything. As a rule, when you need to update the system, there is no choice to switch or not, it is easier to make a new architecture than to dig into the entire monolith.
It is also easy to update a microservice, you don't need to rewrite everything, you add/remove/update only the required module, the work of the rest does not suffer at this time. The main thing is not to forget to correctly connect everything. As a rule, when you need to update the system, there is no choice to switch or not, it is easier to make a new architecture than to dig into the entire monolith.