Monolito vs microservicios: qué cambia realmente en la latencia
· 7 min
Los microservicios suelen justificarse por escala del equipo e independencia de deploy, pero la consecuencia directa en la latencia de esa división suele pasar desapercibida en la discusión.
Una llamada de función se convierte en una llamada de red
Lo que era una llamada de función en el mismo proceso (nanosegundos, sin serialización) se convierte en una llamada de red: serialización, overhead de handshake TCP/TLS (amortizado por el pool de conexiones, pero aún presente) y el round-trip físico, incluso dentro del mismo datacenter esto es órdenes de magnitud más lento que una llamada de función.
La latencia se suma a lo largo de la cadena
Una solicitud de usuario que pasa por N servicios en secuencia tiene su latencia aproximadamente acotada por la suma de cada salto (a menos que las llamadas se paralelicen), así que descomponer un monolito en más servicios dentro del camino crítico de la solicitud agrega latencia directamente, aunque cada servicio individual sea rápido.
Las fallas parciales son un tipo de costo nuevo
En un monolito, un bug o tumba el proceso entero o no tumba nada. En un sistema distribuido, cualquiera de las N llamadas de red puede fallar o quedarse colgada de forma independiente, y manejar eso correctamente, timeouts, retries, circuit breakers, es necesario y, al mismo tiempo, agrega overhead y complejidad que un monolito nunca tuvo que pagar.
Dónde el cambio compensa de todos modos
El costo de latencia es real y vale la pena reconocerlo, pero se cambia por escala y deploy independientes de los servicios que realmente lo necesitan. El error no es elegir microservicios, es dividir un sistema según las fronteras organizacionales de los equipos sin verificar que el grafo de llamadas resultante no metió demasiados saltos de red en el camino caliente de la solicitud.