Developing and deploying applications adhering to microservice architecture comes with its own set of challenges, regardless of which programming language or application framework is used to develop the application:

• Additional operational and tooling overhead: each microservice implementation would require its own (possibly automated) deployment, monitoring systems, and so on.
• Debugging microservices may be more involved than debugging traditional enterprise applications: if an end user reports a problem with their application and that application utilizes multiple microservices internally, it is not always clear which of the microservices may be the culprit. This may be especially difficult if the microservices involved are developed by different teams with different priorities.
• Distributed transactions may be a challenge: rolling back a transaction involving several microservices may be hard. A common approach to working around this is to isolate microservices as much as possible, treating them as single units, then have local transaction management for each microservice. For example, if microservice A invokes microservice B, if there is a problem with microservice B, a local transaction in microservice B would roll back, then it would return an HTTP status code 500 (server error) to microservice A. Microservice A could then use this HTTP status code as a signal to initiate a compensating transaction to bring the system back to its initial state.
• Network latency: since microservices rely on HTTP method calls for communication, performance can sometimes suffer due to network latency.
• Potential for complex interdependencies: while independent microservices tend to be simple, they are dependent on each other. A microservices architecture can potentially create a complex dependency graph. This situation can be worrisome if some of our services depend on microservices developed by other teams who may have conflicting priorities (for example, if we find a bug in their microservice, however, fixing the bug may not be a priority for the other team).
• Susceptible to the fallacies of distributed computing: applications developed following microservice architecture may make some incorrect assumptions, such as network reliability, zero latency, infinite bandwidth, and so on.