Careful consideration must be taken with a microservice architecture. The ideal situation is that each instance can work on its own and pass it along to the nex

Careful consideration must be taken with a microservice architecture. The ideal situation is that each instance can work on its own and pass it along to the next microservice in your application. Having to reach out to other services for additional data would be kept to a minimum. This way, any given instance can be swapped out if or when it's needed without affecting the application. However, as the application grows, it will most likely encounter scenarios where each microservice needs to do something more than what it was originally intended to do. A service might need information from an API or would need to access additional data from a database somewhere before it can work properly. And if that's the case, these hypothetical APIs and databases might be needed in other parts of the application as well. So now instead of everything being structured nicely with interchangable instances, you are now dealing with a network where any given node might not be able to be updated independently of the others. It can quickly become a large mess. That aside, depending on the needs of your application and how it's set up, the various microservices can create a much larger cost than something like a monolithic system. Typically, each service would exist on its own instance, and your hosting provider will happily help you figure out your usage needs and the price that will come along with it.