Independent review of Netflix’s original public Conductor design. Netflix ended maintenance of this public repository on 13 December 2023. The order workflow below is an illustrative business application, not a Netflix implementation or an installation recommendation.
1. Why a chain of integrations becomes hard to operate
A simple automation may call a payment service, create a shipment, and email a customer. The difficult case begins when payment succeeds but the shipment response is lost. Repeating the whole chain can charge again; stopping without a visible state leaves staff unsure what happened.
Netflix’s public Conductor repository describes a platform created to orchestrate workflows across microservices. The useful business concept is an explicit process state: which steps have completed, which are waiting, and which need recovery or a decision.
This is a review of that public design. Netflix announced that it would stop maintaining the original public repository on 13 December 2023 while continuing with its internal fork. Review the maintenance, licensing, compatibility, and support of any present-day option separately before adopting software.
2. Separate coordination from the work being done
In the Conductor model, a workflow coordinates tasks while workers perform the individual operations. The public project supports workflow definitions using JSON and code. Keeping those responsibilities separate makes the overall process easier to inspect without putting every business operation inside one large script.
The application performing a task still owns its real-world effect. A workflow status alone cannot prove that a bank, warehouse, or outside service completed an operation after a network timeout. The design needs a way to query or reconcile that outcome.
Repeated execution also needs deliberate handling. A stable business operation ID can let a service recognize an already-completed request, but the service must actually implement and retain that guarantee. Adding retries to a workflow does not create it automatically.
3. Define an order workflow with clear responsibilities
On small screens, scroll the table sideways to see every column.
| Step | Responsible system | Recovery question |
|---|---|---|
| Validate order | Commerce or ERP | Is the order still eligible, and are its identifiers stable? |
| Reserve stock | Inventory | Did a reservation already exist, and when does it expire? |
| Confirm payment state | Payment integration | Can an uncertain response be reconciled without charging again? |
| Request fulfillment | Warehouse integration | Can the existing shipment request be found by order ID? |
| Notify customer | Communication service | Should the notice be retried, replaced, or held for review? |
Business owners must agree the order of these steps. Authorization, payment capture, stock reservation, and cancellation rules differ between businesses. Treat the table as a project design exercise, rather than a universal payment procedure.
Model waiting states and human review explicitly. An operator should see a meaningful explanation such as “payment outcome needs reconciliation,” with the responsible owner and next action.
4. Walk through a failure without duplicating the order
In the sample scenario, the warehouse accepts a fulfillment request but its response times out. The coordinator records an uncertain outcome against the existing order. Before sending another create request, the integration checks whether the warehouse already has that operation ID.
- If the existing request is found, record its reference and continue from that state.
- If it is definitely absent and retry is safe under the service contract, repeat the same operation with the same identity.
- If the result cannot be determined, move the order to an owned exception queue instead of assuming success or failure.
A compensating action is a separate business operation, such as releasing a reservation or initiating an approved refund. It can also fail or be restricted. Do not represent a multi-system process as a single database transaction that can always be rolled back.
5. Test recovery before moving real orders
Begin by mapping the current manual process and its exception owners. Build one bounded workflow with a test service for each external effect. Simulate timeouts, repeated requests, rejected inputs, unavailable workers, and a task completing after the coordinator has stopped waiting.
Acceptance includes the operator experience: finding the affected order, understanding what happened, and making the permitted correction. Give support staff a runbook and a controlled way to resume or reconcile work. A restart button without an explanation of effects can make an incident worse.
Version workflow definitions and agree how in-flight work is handled when a release changes the process. Pilot a limited order class and retain a documented manual fallback. Production access and external actions remain with the systems and people responsible for them.
6. Measure completion and recovery, not just task speed
Useful measures are end-to-end completion time, waiting time by step, duplicate external effects, unresolved exceptions, and the time an operator needs to recover an order. Define “completed” around the actual business outcome rather than a successful HTTP response.
The public source explains Conductor’s architecture; this article does not reproduce a private Netflix workflow or claim a Netflix business improvement. The order example and delivery plan are original applications of the coordination pattern.
For a smaller process, a well-designed state machine and queue may be sufficient. Reuse explicit state, stable identifiers, and owned recovery before adopting a large orchestration platform.
7. Frequently asked questions
Does Netflix still maintain the original public Conductor repository?
Netflix’s announcement says maintenance of that public repository ended on 13 December 2023. Evaluate any alternative distribution or maintained fork independently; this article reviews the original design.
Do automatic retries prevent failed business transactions?
Retries can help with temporary failures, but they can also repeat external effects. Define operation identity, retry behavior, reconciliation, and human recovery with each connected system.
Is a refund the same as rolling back a workflow?
No. A refund is a separate business action with its own rules, permissions, timing, and possible failures. Multi-system processes need explicit compensation and reconciliation behavior.