PROBLEMA
El robot no debe ser el sistema de registro.
Las automatizaciones de larga duración son frágiles cuando estado, retries y recuperación dependen completamente de una sesión RPA. La solución separa orquestación y ejecución.
CASO DE ESTUDIO 01 · AUTOMATION ENGINEERING
Enterprise Automation Orchestrator
Arquitectura de referencia para automatización empresarial confiable, con el estado durable de orquestación fuera del robot y RPA como un canal de ejecución controlado junto con APIs y servicios.
Request / FastAPI / PostgreSQL / Redis / Workers / API + RPA
DECISIÓN CENTRAL
Separar estado durable y despacho.
PostgreSQL mantiene el estado autoritativo. Redis acelera el despacho. Los workers reclaman trabajo y seleccionan el adaptador API o RPA apropiado.
ARQUITECTURA
La confiabilidad se diseña en cada límite.
01FastAPIAdmisión y validación
02PostgreSQLEstado durable
03RedisSeñal de despacho
04WorkersClaims y retries
05API / RPAEjecución controlada
01
Idempotencia
Identidad lógica para proteger frente a procesamiento duplicado.
02
Recuperación
Retries limitados, backoff, dead-letter y replay auditable.
03
Observabilidad
Métricas, readiness, correlation IDs y base OpenTelemetry.
04
Límite de ejecución
API cuando es viable; RPA cuando la UI es realmente necesaria.
TRADE-OFFS Y LÍMITES
Lo que esta arquitectura no pretende afirmar.
Redis no es la verdad durable
PostgreSQL sigue siendo el estado autoritativo.
Cooldown local
El cooldown del target es local al worker, no un limitador global distribuido.
Tracing
No se afirma propagación completa de contexto a través de toda la frontera asíncrona.
Benchmark
Las pruebas sintéticas son evidencia de ingeniería, no una afirmación de capacidad productiva.
EVIDENCIA
Código, tests, contenedores, CI y decisiones de arquitectura.
Sistema de referencia de portafolio; no se presenta como despliegue productivo de un cliente.