Temporal

Temporal is a durable execution / workflow engine. It solves a specific, painful problem: processes that run for a long time, have many steps with waits in between, and must survive crashes without losing their place. Think order fulfilment, multi-day onboarding, retry-with-backoff over days, or a saga spanning several services. Done by hand with queues and status columns, these get fragile fast. Temporal makes the orchestration itself durable.

The core idea

You write the workflow as ordinary code — a function that calls steps (called activities), waits, branches, loops. Temporal persists the state of that execution as it runs. If the worker process crashes, is redeployed, or the whole thing pauses for three days waiting on a human approval, Temporal resumes the workflow exactly where it left off, with all local variables intact, as if nothing happened.

workflow: charge() → wait for shipment confirmation (could be days)
          → notify() → done
crash mid-way? Temporal replays the history and continues from the last step.

It gets that durability by recording the history of every step and replaying it to rebuild state — so your workflow code must be deterministic (no random, no direct clock/IO in the workflow itself; side effects live in activities).

What it handles for you

• Retries and timeouts on each activity, declaratively — no hand-written backoff loops.
• Long waits — a workflow can sleep for days cheaply; it's not holding a thread.
• State durability — survives deploys, crashes and restarts.
• Visibility — you can see exactly where any running workflow is.
• Compensation / sagas — express "if this fails, undo these" as normal control flow.

When to reach for it (and when not)

Use Temporal when the orchestration is the hard part: many steps, external calls that fail, long waits, human-in-the-loop, and "it must eventually complete or cleanly unwind." Classic fits: payment/fulfilment pipelines, provisioning flows, anything that today is a tangle of cron jobs, status columns and retry tables.

Don't reach for it for "send this email soon" — that's a plain job queue. Temporal is heavier (a server/cluster, SDK, mental model); its value appears only when a simple queue would leave you hand-building durable state and retries.

What to watch

• Operational weight — it's a real system to run (or use Temporal Cloud).
• Determinism rules — workflow code can't do non-deterministic things directly; that trips people up at first.
• It's orchestration, not storage — your data still lives in your databases; Temporal coordinates the steps.

What to say in an interview

Bring it up when a process is long, multi-step and must not lose its place:

"The fulfilment flow is charge → reserve → ship → notify, with waits and external calls that fail. Rather than stitch that together with queues and status fields, I'd run it as a Temporal workflow: each step is an activity with its own retries, the whole thing survives a crash and resumes where it stopped, and a failure triggers the compensations. For the simple 'email after signup' I'd just use a queue."

Next up: API Gateway — the single front door to your services.