If you're dealing with any complex architecture, there will be portions of your service that will be hit more than others. I'm currently building a backend in

If you're dealing with any complex architecture, there will be portions of your service that will be hit more than others. I'm currently building a backend in which will need real time capabilities and also standard restful http services. Separating the real time service which will need a significant amount of performance more than the restful services will help me better scale. Furthermore, the entire backend is written in python, because that is what I'm currently capable of at the moment, but in the future, migrating the real time service to Go will be heavily favorable - by separating it into its own service allows for that rewrite to happen at ease. Now, there are many cases where building microservices are an overkill, but this isn't a one size fits all approach as the author would suggest, and I think we should all be tired of hearing a this or that type of article.