Pattern · seen in 3 breakdowns across 3 companies

Embedded vs Centralized Orchestration

Embedded vs centralized orchestration is where coordination lives: inside each service as a library (isolated, but hard to span services), or in one shared cluster (easy, but a single point of failure).

resilience

The mechanism

The pattern at its core: the same coordination logic arranged two ways - inside each service, or in one shared cluster - and the opposite trades that fall out of that single choice.

LIVE ARTIFACTTHE PATTERN, GENERALOPEN FULL SCREEN ↗
THE IDEAPut the coordination inside each service and a failure stays local, but a workflow that spans services has to be stitched together by hand. Put it in one shared cluster and cross-service workflows are easy, but that cluster is now a single point of failure every service depends on. The same choice buys you isolation or coordination, not both.
WHAT TO TRYRun the three scenarios. A cross-service workflow favours the centralized cluster; a cluster failure favours embedded, which has nothing shared to lose; a single service failing is contained either way.

Run three scenarios across both shapes and watch the trade flip - centralized wins coordination, embedded wins isolation.

Definition

When a system has to coordinate work across several steps - running workflows, retrying, scheduling - there are two ways to arrange it, and they make opposite trades:

  • embedded - the coordinating logic runs inside each service, as a library it imports; each service stays independent, but coordinating across services is hard
  • centralized - the logic runs as one shared cluster every service calls over the network; cross-service coordination is easy, but every service now depends on that one cluster
TWO SHAPES
Two topologies: embedded, with orchestration inside each service; centralized, with all services calling one shared cluster.
Embedded puts the coordination inside each service, so a failure stays local but crossing services is hard. Centralized runs one shared cluster every service calls, so crossing services is easy but the cluster is a single point of failure.

The embedded shape ships as a library. Each service runs its own coordination in-process and keeps the state in the database it already has. If one service's coordination breaks, no other service is touched, and there is no new system to run. The cost is that workflows spanning several services get much harder: you either wire the coordination together by hand, or you accept that each workflow stays inside a single service.

The centralized shape ships as a separate cluster. Every service calls that cluster over the network, and the cluster holds the workflow state and coordinates the steps across services. You get one dashboard for all workflows, support for many languages, and cross-service coordination that just works. The cost is that every service now depends on that cluster staying up, and the cluster becomes a critical thing your team has to tune, scale, and protect. The shared cluster becomes a single point of failure.

Which one wins usually comes down to two questions: do your most important workflows stay inside one service, or span across many services, and can your team take on the work of running a shared cluster?

When it applies

01You are deciding between a library and a shared cluster. Naming the real tradeoff turns it from a matter of taste into a decision about your own constraints.
02A critical service can't rely on a shared dependency. For the services that must never go down, embedded is safer because a failure stays inside that one service.
03Your workflows keep crossing service and language boundaries. When most of the coordination happens between services, a shared cluster starts to make sense.
04You are revisiting a setup that has started to hurt. Maybe the shared cluster keeps causing incidents, or the embedded workflows keep struggling to work across services.

Tradeoffs

Embedded: coordinating across services is hard, and often ends up wired together by hand. Centralized: every service now depends on the shared cluster staying up.
Embedded: each service has to build its own view of what its workflows are doing, with no single dashboard across services. Centralized: one dashboard covers everything, but it is one-size-fits-all and may not fit each service.
Embedded: the coordination is stuck in whatever language the host service uses. Centralized: it usually supports many languages, so a workflow can span services written in different ones.
Embedded: nothing new to run, but every service team quietly owns its own coordination. Centralized: usually one team runs the cluster, which gathers the expertise in one place but gathers the risk there too.

The same move, 3 ways

Every row is a production system that bet on this pattern — the note says how, in that system's own terms.

Airbnb
Airbnb Engineering
2026
The worked example of the embedded side: Airbnb evaluated centralized orchestrators (Temporal/Cadence) and rejected them because a shared cluster is an unacceptable single point of failure for Tier-0 services. Skipper trades cross-service and cross-language reach for failure isolation and zero new infrastructure — the post is unusually explicit that this is the right trade only when minimizing dependencies dominates. Read the breakdown →
Uber
Uber Engineering
2023
This article is the pattern's other pole. Skipper instantiates embedded: engine-as-library, no shared dependency, blast radius contained to one service — at the cost of shipping and operating the engine everywhere. Cadence instantiates centralized: one platform, one team, one availability contract shared by a thousand tenants — at the cost of noisy-neighbor discipline, backward-compatibility drag, and a concentrated database bottleneck. Same crux, opposite answers, both correct for their constraints. Read the breakdown →
Netflix
Netflix Technology Blog
2016
Third company, and the triptych completes: Skipper argues embedded (engine inside the service), Cadence argues centralized (solve durability once), and Conductor is the ancestral centralized case — aimed not at embedded engines but at having no engine at all. Read together, the axis is who owns the process state: the service, the platform, or nobody. Read the breakdown →

Often used together

Patterns sharing breakdowns with this one — derived from co-occurrence, threshold ≥2 shared.

durable-workflows ×3

Problems this pattern answers

The walls where its breakdowns live — each opens the cross-company comparison.

Partial completion under crashesAIRBNB · NETFLIX · UBER →