For Engineering leads with reliability pain
APIs & durable systems
A payment that charges but never fulfils, or a chain of API calls that dies halfway and leaves someone piecing together which steps ran, is usually cleaned up by hand.
Our senior engineers rebuild those operations as durable workflows on Temporal, usually without rewriting your services, so a step that fails at three in the morning resumes from where it stopped and the full history of what happened is there to read.
A chain of calls, with history
Long-running operations that survive restarts and partial failure. Temporal under the lakehouse jobs, agent runs and approvals that must not half-complete.
Temporal turns a fragile chain of API calls into a workflow with history. When a step fails at three in the morning, the workflow resumes from where it stopped rather than from the beginning, and you can read exactly what happened.
- Durable workflows with complete, replayable execution history
- Compensation and rollback paths designed in, not bolted on
- Human-in-the-loop approval gates that survive process restarts
- Migration of existing job chains onto durable execution
How an engagement works
01
Talk to an engineer
A real conversation about your initiative with a senior engineer who has built this before. Not a sales call. What you are trying to build, what has been tried, and what is realistic.
02
Discovery and scoping
Two to three weeks to clarify requirements, evaluate where AI fits, and define realistic scope. On AI work this is also where success gets defined precisely enough to score, because a goal nobody can measure cannot be hillclimbed. You get a plan you can act on before committing to a larger engagement.
03
The right team, daily demos
We put the team the work actually needs on it and show you running software every day. Built with the same rigor as any enterprise system: tested, monitored, documented.
04
Production and beyond
Deployed and running under real load, handling real business processes. Ongoing support and team continuity for whatever comes next.
What durable execution changes in a job chain
Durable execution means the platform records every step a workflow takes, so a crash costs you a pause rather than a restart. In Temporal that record is the workflow's event history. Workflow code decides what happens next.
Activities do anything that touches the outside world, which is every API call, database write and model call, and they're retried for you. When a worker dies, another one replays the history and the code carries on from the line it had reached.
That replay is why workflow code has rules. It has to make the same calls in the same order given the same input, so it can't read the system clock, roll its own random numbers or call a network service directly. Those go through the SDK or into an activity. Most of the bugs in a first Temporal project are somebody calling Date.now() inside a workflow.
The defaults are worth knowing before you trust them. Activities retry by default, starting at one second, doubling each time, capped at a hundred times the first interval, with no limit on attempts and no error type excluded. Workflows don't retry at all unless you give them a policy. So a declined card, retried forever, is the default behaviour until somebody names it in nonRetryableErrorTypes.
Every activity needs a Start-To-Close or a Schedule-To-Close timeout, or Temporal rejects it. A long activity should heartbeat too, because without a Heartbeat timeout a worker that hangs looks exactly like one that's busy. And a workflow's history is capped at 51,200 events or 50 MB, with a warning from 10,240 events or 10 MB. A process that runs for months, polling or batching, has to Continue-As-New into a fresh history well before that.
Sources: Temporal retry policies, activity timeouts, workflow definitions and determinism and workflow execution limits.
An approval that survives a restart, in thirty lines
This is the shape we put in front of an existing chain. Your services stay where they are and become activities. The workflow reserves the money, parks for up to a week waiting for a person, and releases the reservation if nobody approves, which is the compensation step most hand-built chains never get round to.
Restarting or redeploying the workers in the middle of that week doesn't touch the running approval. Changing the workflow's own code does need care, because a run already in flight replays its history against the new code, so the change goes behind patched() or Worker Versioning (Temporal's versioning guide).
import { proxyActivities, defineSignal, setHandler, condition } from '@temporalio/workflow';
import type * as activities from './activities';
const { reserveFunds, releaseFunds, sendStatus } = proxyActivities<typeof activities>({
startToCloseTimeout: '30s',
retry: {
initialInterval: '1s',
backoffCoefficient: 2,
maximumInterval: '1m',
maximumAttempts: 5,
nonRetryableErrorTypes: ['InvalidAccountError'],
},
});
export const approve = defineSignal<[boolean]>('approve');
export async function payout(id: string): Promise<string> {
let decision: boolean | undefined;
setHandler(approve, (ok) => { decision = ok; });
await reserveFunds(id);
const answered = await condition(() => decision !== undefined, '7 days');
if (!answered || !decision) {
await releaseFunds(id); // compensation
return 'released';
}
await sendStatus(id, 'Closed');
return 'closed';
}Sources: the TypeScript workflow API, RetryPolicy and message passing in TypeScript.
Moving an existing job chain onto Temporal
01
Write the chain down as it runs
Every step, the system it calls, what it changes, and whether calling it twice is harmless. The steps that aren't idempotent decide most of the design, and they're rarely the ones the documentation flags.
02
Sort the failures
Which errors are worth retrying and which mean stop. A timeout from a vendor is the first kind. A closed account is the second, and it goes into nonRetryableErrorTypes so it fails once and loudly.
03
Wrap the calls, don't rewrite them
Each existing API call becomes an activity with its own timeout and an idempotency key built from the workflow ID, so a retry after a crash can't charge or send twice.
04
Design the way back
For every step that changes something, the step that undoes it, run in reverse order when a later step fails for good. Where no undo exists, the workflow parks and asks a person.
05
Put the people in the workflow
Approvals become signals or updates the workflow waits on. An update returns a result to the caller, which suits an approval screen that has to show what happened.
06
Cut over one process at a time
New runs start on the workflow while old ones drain on the chain. The history in the Temporal Web UI becomes the audit trail your operators read, and the cron job comes out last.
Is your process a candidate?
- It runs longer than a single request, or waits on a person
- Half-finished runs have to be found and fixed by hand
- A retry has ever sent, charged or written something twice
- Nobody can say where a failed run stopped without reading logs
- A missed step has a legal or financial consequence
- The process outlives a deploy, so it gets restarted in the middle
Checked on 11 October 2026 against Signals, Queries and Updates.
Where we've done it
The repossession close-out is the clearest published case. A Closed status that failed to reach a vendor could mean a wrongful repo. The workflow now holds an assignment from receipt to confirmed transmission, retries a failed call with configurable backoff, and hands it to the operations team when the retries run out.
Athlinks is the same idea at volume, more than 400 million athlete records stitched across sources, where a step that dies mid-run resumes instead of replaying the pipeline.
If you're still deciding whether durable execution is the right model at all, what durable execution is covers the idea on its own, and durable RAG with Temporal and Chainlit shows it under an AI workload.
Related expertise
Expertise pages that sit under this line.
Migrations to Databricks
Off Snowflake, Synapse, Teradata and SQL Server, onto Lakehouse and Lakebase, with a cutover you can reverse.
Data engineering
Pipelines that hold, tables people trust, and a bill that stops surprising you.
Data science & AI
Context stores, memory, retrieval and governed agents that survive production.
AI/BI & Genie dashboards
Genie answers a business question in English, and the answer holds up when somebody checks it against finance.
Machine learning
Models that reach an endpoint, get retrained on a schedule, and can be rolled back by somebody who was not there.
Data & AI governance
Unity Catalog designed so grants hold, lineage survives a refactor, and an agent inherits permissions instead of routing around them.
Forward-deployed teams
Product, design and engineering people who sit inside your business, find the real problem, and ship it.
Product development
Full product delivery: multi-tenant architecture, operator consoles and the data layer under them. On Azure, AWS, Google Cloud or Cloudflare, and as a Databricks App where the product belongs next to the lakehouse.
FAQ
APIs & durable systems, answered
What problem does durable execution actually solve?
Any process with more than a few steps that must not half-complete: a payment that charges but does not fulfil, a repossession that starts but is never recorded, a pipeline that dies mid-run and leaves partial data. Temporal makes the workflow itself durable, so the process survives the infrastructure under it.
Do we have to rewrite our services to use Temporal?
No. The usual pattern is to leave the services alone and put a workflow in front of the sequence that calls them. Your existing APIs become activities. That is how we migrate an existing job chain without a rewrite.
How is this different from a queue and retries?
A queue gives you delivery. It does not give you the state of a business process. Temporal keeps a complete, replayable history of the workflow, so you can answer what happened, where it stopped and what compensating action ran, without reconstructing it from logs.
Can a human approval sit in the middle of a workflow?
Yes, and it survives a restart. A workflow can park for days waiting on a signal, then continue from exactly where it stopped. We use that pattern in our own systems for anything that leaves the workspace.
Do you work with Temporal Cloud or self-hosted?
Both. TechFabric is a Temporal partner and we have certified durable paths against Temporal Cloud, including a workflow that survived a full application restart and completed from its original history.