Long-running processes
Process Automation
Real business processes span services and run for seconds, days, or weeks — and anything can fail in the middle. This track covers why long-running processes are hard, how to make them explicit with BPMN and workflow engines, when to orchestrate vs choreograph, and how to operate them with full visibility.
Mark a topic “learned” on its page and watch the bars fill.
Skill map
Learned nodes light up — the glowing one is your next step. Click any node to jump in.
Foundations
Why long-running processes are hard — state, time and failure across services, and where orchestration beats hand-rolled glue.
The moment your logic crosses a boundary it becomes long-running — and you inherit state, time, and failure problems that a workflow engine exists to solve.
✦ Complete · ⏱ 5 min 2 · Beginner Orchestration vs ChoreographyOrchestration is command-driven, choreography is event-driven — and the real architecture choice is made link by link, based on who owns the outcome.
✦ Complete · ⏱ 5 min 3 · Beginner Where Workflow Engines FitA workflow engine is a persistent, scheduling state machine — run it as a service, keep it decentralized, and judge its adoption by return on investment.
✦ Complete · ⏱ 5 minModeling & Orchestration
Making processes explicit — BPMN and executable workflow models, orchestration vs choreography, and workflow engines.
BPMN is an ISO-standardized notation that is diagram and source code at once — learn its tokens, tasks, gateways, and events even if you use another language.
✦ Complete · ⏱ 5 min 5 · Intermediate Executable Workflow ModelsA model becomes executable by connecting it to glue code — prefer publish/subscribe, treat the model as source code, and plan for versioning from day one.
✦ Complete · ⏱ 5 min 6 · Advanced The Saga and CompensationACID stops at the service boundary — the saga pattern restores consistency by undoing completed steps with compensating actions instead of rolling back.
✦ Complete · ⏱ 5 minBuilding & Operating
Production automation — integrating with services, handling failures and compensation, visibility into running processes, and organizational adoption.
Orchestrate anything with an API — and respect boundaries: synchronous or async calls, correlation, and clean result-only APIs instead of the hot-potato anti-pattern.
✦ Complete · ⏱ 5 min 8 · Advanced Handling Failures and RetriesRemote calls are unreliable — keep failures local with stateful retries, design every operation to be idempotent, and clean up after ambiguous failures.
✦ Complete · ⏱ 5 min 9 · Intermediate Visibility and Organizational AdoptionProcess context is what makes monitoring valuable — and visual, executable models are the shared language that bridges the business–IT gap across BizDevOps.
✦ Complete · ⏱ 5 min⚙️ Make the process explicit, or it hides in the gaps
When a long-running process is implicit — scattered across event handlers and retries — no one can see its state or fix it when it stalls. An executable workflow model turns that invisible flow into a first-class, observable, recoverable artifact. Orchestrate the steps you need to reason about; choreograph the rest.