Diseñar microservicios escalables
Los límites de servicio tienen un costo. Escala los que el dominio realmente necesita; deja el resto como un monolito modular hasta que la costura sea real.
Experiencia personal
El liderazgo técnico en una plataforma de ecommerce (Armirene) y el liderazgo de I+D en un ERP privado (Soga) exigen el mismo juicio: dónde un límite vale el costo operativo, y dónde no.
Perspectiva técnica
Un microservicio no es una unidad desplegable que resulta ser pequeña. Es una unidad de propiedad de datos, de fallo y de release. Si dos servicios no pueden cambiar de forma independiente — porque comparten base de datos, un lock o un tren de releases — no son servicios. Son un monolito distribuido con latencia extra.
La primera pregunta de escala no es Kubernetes. Es: ¿cuál es la unidad de contención? Si el cuello de botella es una tabla, partir el proceso que escribe en ella no ayuda. Si el cuello de botella es la cadencia de release de un equipo, un límite de servicio puede ayudar. Si el cuello de botella es una API de terceros, ninguno de los dos lo hará.
Los contratos deben versionarse, ser aburridos y explícitos. El fan-out síncrono entre muchos servicios es cómo desaparece el presupuesto de latencia. Prefiere una API gruesa en el borde y deja el chatter detrás de ella.
Architecture
Borde grueso, servicios independientes
Client
API Gateway
Service A
Service B
Service C
Owned data stores
Perspectiva técnica. Un gateway debe ocultar el chatter interno, no multiplicarlo.