La mayoría de las reescrituras de software no ocurren porque el código sea malo. Ocurren porque la arquitectura fue diseñada para el producto de hoy, no para el negocio de mañana. Escalar no es agregar servidores: es tomar decisiones tempranas que no se conviertan en deuda técnica.
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. Los servicios se comunican a través de contratos explícitos (APIs, eventos) sin compartir bases de datos.
Contratos claros, no acoplamiento oculto
El acoplamiento más peligroso no está en el código: está en los datos. Dos servicios que leen de la misma tabla eventualmente chocarán en producción. La solución es que cada servicio sea dueño de sus datos y que las integraciones ocurran vía APIs versionadas o eventos de dominio.
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.