CASE STUDY 01 · AUTOMATION ENGINEERING
A reference architecture for reliable enterprise automation where durable orchestration state lives outside the robot and RPA is one controlled execution channel among APIs and services.
PROBLEM
Long-running enterprise automations become fragile when execution state, retry behavior and recovery depend entirely on a bot session. The design separates orchestration from execution so work can be claimed, retried, audited and recovered independently.
CORE DECISION
PostgreSQL owns durable request state. Redis accelerates dispatch. Workers claim work and select the appropriate API or RPA adapter. Robot availability does not define the reliability model of the whole system.
ARCHITECTURE
Logical request identity protects against accidental duplicate processing.
Bounded retries, backoff, dead-letter handling and auditable replay.
Metrics, readiness, correlation IDs and OpenTelemetry foundations.
Prefer supported APIs; use RPA where UI interaction is genuinely required.
TRADE-OFFS & LIMITS
Dispatch is recoverable because PostgreSQL remains the authoritative state store.
Target cooldown is worker-local in the reference implementation, not a distributed global limiter.
OpenTelemetry exists, but complete trace-context propagation across the asynchronous boundary is not claimed.
Synthetic admission testing is engineering evidence, not a production-capacity claim.
EVIDENCE
This is a portfolio/reference system built to demonstrate automation engineering patterns. It is not presented as a client production deployment.