Microservices are often adopted to improve performance, fault tolerance, system boundaries, and deployment flexibility. However, practical implementation often reveals that these benefits are offset by significant overhead, such as network latency and serialization costs.
Tests show that calling a function via HTTP or gRPC consumes 3.5 times more resources than an in-process call, while RabbitMQ usage increases resource consumption by 6.3 times. Consolidating components into a single process can significantly reduce latency and CPU usage.
Research by Google engineers on the Online Boutique application demonstrated that moving 11 microservices into a single process resulted in 9 times lower resource usage and 14 times lower latency compared to the original distributed architecture.
Fault tolerance in microservices is often theoretical, as cascade failures frequently occur and testing recovery logic is complex. Distributed systems also introduce challenges like data consistency, requiring application-level joins instead of database-level operations.
A case study of the eShop application showed that migrating from ten microservices to three modular units reduced memory usage by 75%, CPU usage by 81%, and total server code by 39%, while also identifying seven defects.
