The video demonstrates that microservices incur significant performance overhead compared to monolithic applications, often requiring roughly double the CPU resources to handle the same load due to network communication and resource inefficiencies. However, despite this slowdown, microservices provide benefits like team autonomy, scalability, and fault isolation, making them valuable for complex systems, while modular monoliths may serve as a practical middle ground for many applications.
The video explores the performance trade-offs when splitting a monolithic application into microservices, specifically comparing an eight-core machine running a monolith versus four two-core machines running microservices with the same total resources. Traditionally, monoliths were deployed on single machines or scaled horizontally by replicating the entire application. Microservices, however, allow different teams to own and deploy separate services independently, offering flexibility and scalability but introducing overhead due to network communication between services. The presenter built both versions of a medium-style application called Conduit, using Go and PostgreSQL, to measure the real-world performance impact of this architectural shift.
In the experiments, the monolith on a single eight-core machine handled 60,000 users, while running four replicated monoliths on four smaller machines dropped capacity to 50,000 users due to overhead from multiple operating systems and networking. Splitting the application into four microservices on the same eight-core machine reduced capacity drastically to 25,000 users with HTTP communication, mainly because inter-service calls replaced simple function calls, adding CPU overhead for request handling and encoding. Switching to gRPC for internal communication improved performance slightly, raising capacity to 29,000 users by reducing serialization costs.
Distributing the microservices across four two-core machines further lowered capacity to 18,000 users with HTTP and 19,000 with gRPC, highlighting inefficiencies in resource allocation where some services were CPU-bound while others were underutilized. By reallocating resources and adding replicas for busier services without increasing total hardware, the presenter improved capacity to 20,000 users with HTTP and 30,000 with gRPC, showing that careful hardware distribution can mitigate some performance losses. However, even the best microservices setup still fell significantly short of the monolith’s performance, requiring roughly double the CPU cores to handle the same load.
The video also discusses potential optimizations not tested here, such as giving each microservice its own database infrastructure, caching frequently accessed data locally, or offloading work asynchronously to reduce response times. These approaches come with trade-offs in complexity, consistency, and operational overhead. Despite the performance cost, microservices offer benefits in team autonomy, faster and smaller deployments, technology diversity, and fault isolation, which can be crucial for large organizations managing complex systems. The presenter cautions that these benefits only materialize if teams achieve true independence and design for resilience.
In conclusion, while microservices introduce significant performance overhead compared to monoliths, their architectural advantages can justify the cost in many scenarios. The presenter suspects that modular monoliths may become the default starting point for many applications, especially as AI empowers smaller teams to handle more work efficiently without the complexity of microservices. The video encourages viewers to consider both performance and organizational factors when choosing between monoliths and microservices and invites feedback and further discussion through the presenter’s newsletter and channel.