Monolito vs microsserviços: o que realmente muda na latência
· 7 min
Microsserviços costumam ser justificados por escala de time e independência de deploy, mas a consequência direta na latência dessa divisão costuma passar batido na discussão.
Uma chamada de função vira uma chamada de rede
O que era uma chamada de função no mesmo processo (nanossegundos, sem serialização) vira uma chamada de rede: serialização, overhead de handshake TCP/TLS (amortizado por pool de conexões, mas ainda presente) e o round-trip físico, mesmo dentro do mesmo datacenter isso é ordens de magnitude mais lento que uma chamada de função.
Latência soma ao longo da cadeia
Uma requisição de usuário que passa por N serviços em sequência tem sua latência aproximadamente limitada pela soma de cada salto (a menos que as chamadas sejam paralelizadas), então decompor um monolito em mais serviços no caminho crítico da requisição adiciona latência diretamente, mesmo que cada serviço individual seja rápido.
Falhas parciais são um tipo de custo novo
Num monolito, um bug ou derruba o processo inteiro ou não derruba nada. Num sistema distribuído, qualquer uma das N chamadas de rede pode falhar ou travar de forma independente, e lidar com isso corretamente, timeouts, retries, circuit breakers, é necessário e, ao mesmo tempo, adiciona overhead e complexidade que um monolito nunca precisou pagar.
Onde a troca compensa mesmo assim
O custo de latência é real e vale reconhecer, mas ele é trocado por escala e deploy independentes dos serviços que realmente precisam disso. O erro não é escolher microsserviços, é dividir um sistema pelas fronteiras organizacionais dos times sem checar se o grafo de chamadas resultante não colocou saltos de rede demais no caminho quente da requisição.