An educational benchmark walkthrough comparing a Go monolith with four microservices under the same application-server budget. It tests HTTP versus gRPC, one large server versus four smaller servers, and resource allocation, then considers scaling, team independence, and failure isolation. 0:20 1:53 10:53 11:50
Topic breakdown
- Architecture basics and the question being tested
- Application design and experimental controls
- Hardware, workload, and scoring
- Single-server and replicated monolith baselines
- Same-server HTTP microservices and CPU overhead
- What gRPC improves
- Four-server deployment and resource rebalancing
- Scaling and serverless compute estimates
- Untested optimization options
- Team independence, blast radius, and architectural choice
The original transcript preserves the full source and timestamp links.
Key takeaways
- The single-server monolith held 60,000 users at about 15,400 requests/second. Four replicated monoliths held 50,000 users, about 17% less capacity despite equal total vCPU and RAM.
4:565:16 - Splitting into HTTP/JSON services on the same large server reduced capacity to 25,000 users. Application CPU per public request rose from about 0.47 ms to 1.2 ms, over 2.5 times as much work.
5:396:20 - Internal gRPC raised same-server capacity to 29,000 users and reduced CPU work to about 1.01 ms/request, but retained the service dependency chain.
6:467:05 - On four servers, rebalancing raised gRPC capacity from 19,000 to 30,000 users, roughly 58%, without adding hardware. This best microservices result still held 50% fewer users than the large monolith and 40% fewer than the replicated monolith.
7:598:2110:53 - In the rebalanced layout, gRPC used about 0.91 ms CPU/request versus HTTP's 1.27 ms, a measured CPU reduction of about 28%.
8:218:46 - Microservices can justify additional compute through independent releases and failure isolation, but both benefits require deliberate boundaries and dependency handling. Separate services alone do not guarantee either benefit.
11:1111:3511:50