# netflix-conductor Published articles for netflix-conductor. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Netflix Conductor: The Next Chapter DevFeed: [Netflix Conductor: The Next Chapter]() Original publisher: [Read original article]() Author: Netflix Technology Blog Published: 2026-10-14T19:50:17Z Content type: article Language: en Sources: [Netflix]() Topics: [Plover](), [Cloud Architecture](), [internal developer platform automation]() Tags: [architecture](), [cassandra](), [concurrency](), [data](), [developer](), [developer-experience](), [distributed-systems](), [engine](), [growth](), [netflix-conductor](), [open-source](), [orchestration](), [workflow]() ### AI overview Netflix describes how it rebuilt and expanded Conductor, its workflow orchestration engine, to handle growing workloads. The article covers changes to its data plane and evaluation engine, asynchronous processing, concurrency controls, managed compute, dynamic worker-thread allocation, and a type-safe Java Workflow SDK. ### Source excerpt Netflix Conductor : The Next Chapter by Aravindan Ramkumar on behalf of the Conductor team Conductor is the workflow orchestration engine Netflix uses to stitch micro-services into reliable, observable business processes. If you've followed Conductor from the outside, the last thing you heard was probably the note on its GitHub repository: Netflix discontinued maintenance of Conductor OSS to refocus its resources on the internal fork. That announcement marked the end of the open-source chapter, and from the outside it may have looked like the end of the story. It wasn't. Internally, Conductor never slowed down. If anything, it grew faster, and the demands of that growth pushed us to rebuild it from the ground up. This post is the answer to the natural question that announcement leaves open: what happened to Conductor after that? A lot, it turns out. The clearest way to put it is in terms of growth. Not long ago, Conductor crossing a billion workflow executions in a single year felt like a milestone. Today it clears that bar roughly every quarter, and the monthly volume is still climbing. Sustaining that kind of growth meant rethinking nearly every layer of the system. The data plane it runs on was modernized piece by piece. The evaluation engine was rewritten. The way it allocates work, controls concurrency, and runs compute all changes. The through-line is simple: scale forced a rethink of the evaluation engine and the layers beneath it, and everything else followed. The rest of this post walks through that evolution: how the architecture changed, the performance and scale work at the heart of it, the leap forward in developer experience, and the newer capabilities for controlling how workflows and tasks execute. How Netflix uses Conductor When we last wrote about Conductor, it ran a few hundred workflow definitions for a few dozen teams. That footprint has grown by orders of magnitude. Conductor now backs roughly 200,000 workflow definitions owned by around 150 ap