Temporal Workflow (durable execution)

Write a long-running workflow as classic functional code, but with durable execution: automatic retry, post-crash recovery, durable sleeps. The Temporal promise — fork of Cadence (Uber) — applied to EDI orchestrations.

Problem

Writing a PO/ORDRSP/DESADV/INVOIC/REMADV saga workflow that can last 30 days, manages retries on external calls, persists state between crashes, is observable: it is complex. Classic solutions impose either a BPMN (Camunda) with a learning curve, or a custom orchestrator (polling loop + DB + manual retry), or verbose JSON Step Functions. The workflow code is diluted in the orchestration machinery.

Forces

• EDI workflows last long: a PO → REMADV saga can span 30-60 days.
• Retries must be robust: every external call (validation, ERP, partner) can transiently fail.
• State must survive crashes: a dying process or Kubernetes node must not lose the workflow.
• Code must stay readable: business logic should not drown in orchestration plumbing.
• Observability is required: ability to see each workflow's state, full event history.

Solution

Temporal (and its ancestor Cadence) offers a durable execution primitive: workflow code is written as normal functions, the SDK guarantees that each deterministic call is faithfully replayed after crash. Activities (side-effect calls) are retried automatically per declarative retry policy. Timers enable durable sleeps of days. Signals allow external event injection into a running workflow. The Temporal server stores the full event history in Cassandra or PostgreSQL — this log guarantees durability.

Temporal architecture:

   ┌───────────────────────────────────────┐
   │   Application code (Workflow + Activities) │
   │   - Workflow: orchestration code            │
   │   - Activity: side-effect call (HTTP, DB)   │
   └───────┬─────────────────┬─────────────────┘
           │                 │
       SDK (Go/Java/Python/TS)
           │                 │
           ▼                 ▼
   ┌──────────────────────────────────┐
   │   Temporal Server                │
   │   - History service: event log   │
   │   - Matching service: task queue │
   │   - Frontend / Worker            │
   └──────────┬───────────────────────┘
              │
              ▼
   ┌──────────────────────────────────┐
   │   Persistence (Cassandra/Postgres)│
   │   stores full event history      │
   └──────────────────────────────────┘

   Workflow code is REPLAYED at each wake-up. Event history
   guarantees determinism. Activity retries are automatic.
   Timer = durable sleep. Signal = external event injection.

EDI implementation

Concrete case: PO → ORDRSP → DESADV → INVOIC → REMADV saga workflow for an automotive partner. Simplified Temporal (TypeScript) code: async function orderSaga(input: OrderInput) { const ordrsp = await sendPO(input); await wait('48h'); const desadv = await receiveDesadv({...}); const invoice = await receiveInvoice({...}); const remadv = await sendPayment({...}); return remadv; }. Each call sendPO, receiveDesadv is a retryable activity. The wait('48h') is a durable timer. If the worker crashes during the wait, the workflow resumes where it was. If the partner is down for 4 days, transparent retry waits. The Temporal dashboard shows each saga's state with event history. The workflow code keeps the readability of a business function. 2026 production: Datadog, Snap, Stripe, Doordash, HashiCorp Vault use Temporal for critical workflows. Open-source alternative: Cadence (original Uber fork), io.temporal.* official SDK.

Anti-patterns

• Non-deterministic code in the workflow: Math.random(), Date.now() directly in the workflow — replay diverges. Always use Temporal APIs (workflow.random, workflow.now).
• Too short activities: each activity has a network overhead, multiplying trivial activities saturates the system. Business-meaningful granularity.
• Workflows too long in memory: a workflow accumulating 100k events in memory becomes heavy. For multi-month sagas, use ContinueAsNew.
• Business logic in activities: the activity must be a minimal wrapper around the external call; any logic goes in the workflow.
• No error handling: default retry without circuit breaker or timeout = retry storms during prolonged partner outage.

Related patterns

• Process Manager — parent EIP pattern.
• EDI State Machine — Temporal is one implementation.
• Saga Orchestration — pattern naturally implemented in Temporal.
• Step Functions — AWS managed variant.
• Compensating Action — pattern naturally written as a Temporal activity.

Sources

• Temporal Documentation. Canonical reference for writing durable workflows with Temporal. docs.temporal.io
• Temporal Blog — Workflow Execution Model. Detailed explanation of replay and durability. temporal.io — workflow-engine-principles
• Cadence Documentation (Uber). The original open-source fork from which Temporal originated. cadenceworkflow.io
• Fateev M., Manas S. — Temporal: A Cloud-Native Programming Model for Reliable Distributed Applications, QCon and InfoQ talks 2020-2023.
• Newman S. — Building Microservices, O'Reilly 2015 (2nd ed. 2021). Chapter on saga choreography vs orchestration.
• Richardson C. — Microservices Patterns, Manning 2018. Chapter 4 on Sagas and their orchestration implementation.