Automatizar no obliga a distribuir
Un proceso automático puede vivir perfectamente dentro de una aplicación modular. Separarlo en otro servicio introduce despliegues, observabilidad, autenticación, contratos de red y consistencia distribuida. Ese coste solo se justifica cuando resuelve un límite real.
La primera pregunta debería ser qué parte cambia a otro ritmo, necesita escalar de forma independiente o tiene requisitos operativos distintos. Si no existe una respuesta concreta, un módulo bien delimitado suele ser una mejor base.
Una secuencia práctica
La automatización puede evolucionar por capas. Cada paso añade una capacidad observable sin asumir de entrada la arquitectura más costosa.
- Extraer la lógica a un servicio interno con una interfaz clara.
- Ejecutarla fuera de la petición web mediante un job.
- Añadir una cola cuando se necesiten reintentos, prioridad o control de concurrencia.
- Separar el proceso en otro despliegue solo si existe una razón operativa medible.
Idempotencia y estados explícitos
Un job debe poder ejecutarse dos veces sin duplicar una factura, un correo o un movimiento de stock. Esto requiere una clave de idempotencia o un registro de ejecución asociado al objeto de negocio.
También ayuda evitar estados ambiguos. Pendiente, en proceso, completado y fallido son más operables que un único campo booleano. Si el flujo es importante, guardar cuándo y por qué cambió de estado reduce mucho el tiempo de diagnóstico.
El criterio: reducir carga operativa
La arquitectura correcta es la que hace el proceso más confiable sin trasladar el trabajo manual a la infraestructura. Una automatización que exige revisar cinco servicios y tres dashboards para entender un fallo no ha reducido la complejidad; solo la ha movido.
¿Estás trabajando en un problema parecido?
Hablemos ↗