Software Architect · Módulo 11
Un monolito no significa caos, y los microservicios no significan arquitectura. Lo que importa son los boundaries, el ownership y la madurez operacional.
Modular monolith · service boundaries · operational complexity
Los microservicios compran independencia al precio de la complejidad distribuida. Si no necesitas la independencia, el precio sobra.
Un servicio es una unidad organizacional
Una oficina aparte ayuda cuando el equipo tiene su propio trabajo, ritmo y responsabilidad. Si todos están igual en la misma call, las paredes no sirven.
Un microservicio se justifica cuando el contexto tiene su propio lifecycle, su equipo owner, su perfil de carga, sus requisitos de seguridad o su ritmo de release. No basta con sacar el código a un deployable unit aparte.
Un modular monolith suele ser mejor al principio: un solo codebase y un solo deployment, pero módulos internos estrictos, interfaces públicas, sin dependencias circulares y un ownership claro.
La distribución suma un precio operacional
Una cocina puede ser estrecha. Diez cocinas exigen logística, comunicación, horarios de entrega y reglas para pasar los platos.
Los microservicios exigen service discovery, observability, network security, contratos backward-compatible, distributed tracing, deployment orchestration, incident response, data ownership y prácticas SRE. Nada de eso es una desventaja si hay una razón. Es el precio.
El arquitecto tiene que preguntarse honestamente: ¿qué dolor desaparece después del split y qué dolor nuevo aparece?
Un buen split reduce la coordinación. Un mal split crea más reuniones de aprobación que las que había antes.
Ejemplo: extraer billing
La caja, la contaduría y el almacén están conectados, pero la contaduría tiene sus propias reglas, auditorías y responsabilidad.
Billing tiene sus propios requisitos de compliance, audit trail, integraciones con payment providers y un equipo owner. Se puede extraer a un servicio con sus propios datos y contratos: invoices, subscriptions, payment events.
Ese split tiene sentido: protege un dominio con alto costo de error y con un ritmo de cambio aparte.
Antiejemplo: un microservicio por tabla
Si cada estante del almacén se vuelve una tienda aparte, el cliente tiene que pasar por diez cajas para un solo pedido.
El equipo construye users-service, profiles-service, addresses-service, roles-service, pero cualquier use case exige llamadas a los cuatro. Los datos siguen acoplados, los releases siguen siendo coordinados, y la latency y el debugging empeoraron.
Eso es un distributed monolith: hay servicios, pero no hay independencia.
- ¿Qué equipo será owner del servicio? - ¿Puede el servicio releasearse de forma independiente? - ¿De qué datos es owner? - ¿Qué nuevas operational responsibilities aparecen después del split?