Para preparar una aplicación empresarial para crecer, separa responsabilidades, define contratos entre módulos y mide latencia, errores y recursos antes de ampliar infraestructura. Una primera versión puede ser una sola aplicación organizada en módulos; los servicios independientes se justifican cuando la carga, los despliegues o el equipo lo requieren.
Servicios bien limitados
La regla más simple y más ignorada en arquitectura de software: un servicio debe hacer una cosa y tener una razón para cambiar. Cuando un módulo mezcla lógica de negocio, acceso a datos y presentación, cualquier cambio toca todo el sistema.
En la práctica, esto significa definir contextos delimitados (bounded contexts en Domain-Driven Design): cada área del negocio —ventas, inventario, facturación, logística— tiene su propio modelo de datos, su propio contrato y su propia responsabilidad. Si esas áreas se despliegan como servicios independientes, pueden comunicarse mediante contratos explícitos (APIs, eventos). En una aplicación modular también deben tener responsabilidades y accesos a datos definidos.
Contratos claros, no acoplamiento oculto
Cuando varios servicios modifican la misma tabla, un cambio de estructura puede afectar a todos. Define quién puede escribir cada dato y cómo se comunican los cambios. Para servicios independientes, las APIs versionadas o los eventos permiten hacer explícitas esas dependencias.
Observabilidad desde el día uno
No puedes escalar lo que no puedes medir. La observabilidad —logs estructurados, métricas de negocio, trazabilidad distribuida— no es un lujo de equipos grandes. Es la diferencia entre detectar un problema en segundos o enterarte por un cliente enojado tres días después.
Desde la primera iteración, cada servicio debe exponer: logs con contexto de negocio, métricas de latencia y error, y health checks que confirmen que las dependencias están operativas.
Decisiones que evitan reescrituras
- Separar lectura y escritura (CQRS). No siempre necesitas CQRS completo, pero entender que los patrones de consulta y comando son distintos evita cuellos de botella tempranos.
- Diseñar para el reemplazo. Cada integración externa debe tener una capa de abstracción. Si cambias de pasarela de pagos, el resto del sistema no debería enterarse.
- Postergar decisiones de infraestructura. La base de datos, el message broker y el orquestador se eligen cuando los requerimientos son claros, no antes.
Una arquitectura escalable no es la que soporta más usuarios: es la que permite cambiar de opinión sin reescribir el sistema.