iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A durable workflow is a multi-step process whose progress is saved by the platform, so it can survive a crashed server, a restarted worker, or a long wait for a human or external system and then continue where it left off. Cadence, an open-source workflow orchestration platform that originated at Uber, is one implementation of this idea. Uber’s own documentation uses an Uber Eats order as its worked example, and that example is the clearest way to see what durable execution does and what it does not claim.
What a durable workflow is
Most business processes are not a single function call. Placing a food order involves validating a cart, charging a payment method, notifying a restaurant, waiting for acceptance, scheduling a courier, and tracking delivery. Each step can fail, take minutes or days, or need a retry. In a conventional design, each team writes its own queues, database status columns, retry loops, and timeout jobs to stitch these steps together. When something goes wrong midway, the recovery logic is usually the least-tested part of the system.
Durable execution moves that bookkeeping into the platform. The workflow is written as ordinary code, and the platform records every meaningful event in the workflow’s history. If the process running that code disappears, the history is still there, and a healthy worker can rebuild the workflow’s state from it and resume. The workflow code is the source of truth for the business sequence; the platform is responsible for not losing track of where that sequence stands.
Cadence at a glance
Cadence is an open-source, code-driven workflow orchestration platform created at Uber. Uber announced Cadence 1.0 on June 22, 2023, in an Uber Engineering post titled “Announcing Cadence 1.0: The Powerful Workflow Platform Built for Scale and Reliability.” Current project documentation describes Cadence as having joined the Cloud Native Computing Foundation as a Sandbox project in 2025. That is the project’s own status statement; check the CNCF project listing before relying on it for a procurement or governance decision.
#1 Best Overall
Cadence’s documentation positions durable orchestration for work that spans more than a single request-response cycle. The use cases it lists include long-running processes, multi-step orchestration, retry-heavy integrations, polling, and event-driven applications.
The Uber Eats example, stage by stage
Cadence’s Go package documentation illustrates the model with an Uber Eats business flow. The example covers five areas:
- Order placement and acceptance: the customer submits an order and the restaurant accepts or declines it.
- Cart processing: items, prices, and promotions are validated before money moves.
- Food preparation and delivery coordination: the kitchen works on the order while delivery is arranged around it.
- Delivery scheduling: a pickup time is set and may need to change as the order progresses.
- Payments: charging and settlement happen as part of the same business process.
This is a documentation example written to explain the model. It is not a detailed description of Uber’s internal deployment, service boundaries, or how many services or databases the production system uses. It also does not state that each named stage maps one-to-one to a particular activity or microservice, so readers should not assume that mapping.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWorkflow versus activity
Cadence separates two kinds of code. A workflow coordinates the process: it decides what happens next, in what order, and what to wait for. An activity performs one concrete business operation, such as calling a payment provider or sending a restaurant notification. The workflow itself must be deterministic, because the platform may re-run it during recovery and expects the same decisions to come out again. Activities are where side effects live.
| Aspect | Workflow | Activity |
|---|---|---|
| Role | Coordinates the sequence of steps | Performs one business operation |
| Typical content | Decisions, ordering, waits, and branching | Calls to external systems, database writes, notifications |
| Recovery behavior | Rebuilt by replaying persisted event history | Re-executed under the configured retry behavior if it does not complete |
| Example from the order flow | The sequence “validate cart, charge, schedule delivery” | “Charge the customer’s card” |
The table describes the documented division of responsibility. Exact retry settings and timeouts are configured by the implementer and are not specified by the Uber Eats example.
How a workflow recovers after a worker crashes
Cadence’s documentation says the service persists execution events and that workers execute the workflow and activity code. Recovery follows from that split:
- The workflow records each completed step, such as a successful activity result or a timer firing, as an event in its history.
- A worker running the workflow code stops, whether because of a crash, a deploy, or a machine failure.
- The history remains in the Cadence service, unaffected by the worker’s loss.
- Another worker picks up the workflow and replays the code against the stored history. Steps already recorded return their saved results instead of running again.
- The workflow continues from the first step that has no recorded outcome.
This is the replay model the documentation describes. It is why the workflow code must be deterministic: a worker that makes different decisions during replay would put the workflow’s state out of step with its history.
Recommended Free Tools
Waiting without a polling loop
A workflow can also wait for something that may take hours or days. Cadence’s documented capabilities include durable timers, external signals, child workflows, and asynchronous activity completion. A timer lets a workflow pause for a set duration, and a signal lets an outside system push new information into a running workflow, such as a courier confirming pickup. The waiting state is stored in the workflow’s history, so no worker needs to stay busy polling a database table for the event.
The Uber Eats example is useful for this because scheduling and delivery depend on events that arrive at unpredictable times. The documentation does not establish that every named Uber Eats workflow uses each of these features; it establishes that the features exist in Cadence.
What Uber reports about developer effort
In the Cadence 1.0 announcement, Uber reported that an internal 2021 survey found teams wrote 40% less code to implement the same functionality with Cadence. This is Uber’s own attributed result, not an independently verified benchmark. The sample size and survey method are not stated in the portion of the announcement this article relies on, so the figure should be read as a reported internal finding rather than a general measure of productivity.
The announcement’s author, Ender Demirkaya, also explained the design reasoning behind the platform:
“However, simplicity should be on the workflow writing side instead of the orchestration; simply because the orchestration engine is built once, while a unique workflow needs to be written for each use case.”
That statement describes the trade-off Cadence makes: the platform team carries the complexity of orchestration once, and application teams write the business logic for each workflow.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Comparing Cadence with a hand-built design
The documentation contrasts Cadence with a setup where each team coordinates queue consumers and database rows using its own retry, timer, and recovery logic. The point is not that such designs are inherently worse. A simple two-step process may not need an orchestration engine at all. The useful questions for choosing between approaches are these:
- Authoring model: is the process written as code, or defined through a DSL or configuration?
- State ownership: who stores progress, and who is responsible for retries and recovery logic?
- Long waits: does the process need durable timers or external signals that last days?
- Visibility: can operators see where each instance is and why it stopped?
- Operations: will your team run the cluster, or use a managed deployment offered by a partner, as the Cadence documentation describes?
- Language fit: does your team’s runtime have a supported Cadence client?
These are comparison axes, not a sourced verdict. No independently published benchmark comparing Cadence with other orchestration products or queue-based designs was established for this article.
What the evidence supports
Cadence is an open-source orchestration platform from Uber, built around persisted event history, deterministic workflow code, and replay. The Uber Eats example shows how a multi-stage order can be modeled as one workflow with activities doing the external work. The developer-effort figure is Uber’s own 2021 internal result, and it should be read with that attribution. Anyone evaluating the approach for their own system should test it against their own failure scenarios rather than rely on the example’s structure as a map of Uber’s production architecture.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
