Monolith vs microservices: what actually changes in latency
· 7 min
Microservices are usually justified by team scaling and independent deploys, but the direct latency consequence of that split tends to get glossed over in the discussion.
A function call becomes a network call
What used to be an in-process function call (nanoseconds, no serialization) becomes a network call: serialization, TCP/TLS handshake overhead (amortized by connection pooling, but still there), and the physical round trip, even within the same datacenter this is orders of magnitude slower than a function call.
Latency adds up along the chain
A user request touching N services in sequence has its latency roughly bounded by the sum of each hop (unless calls are parallelized), so breaking a monolith into more services on the request's critical path adds latency directly, even if each individual service is fast.
Partial failures are a new kind of cost
In a monolith, a bug either crashes the whole process or it doesn't. In a distributed system, any one of N network calls can fail or hang independently, and handling that correctly, timeouts, retries, circuit breakers, is both necessary and itself adds overhead and complexity a monolith never had to pay for.
Where the trade still pays off
The latency cost is real and worth acknowledging, but it's traded for independent scaling and deployment of the services that actually need it. The mistake isn't choosing microservices, it's splitting a system along team boundaries without checking whether the resulting call graph puts too many network hops on the request's hot path.