Runtime
A workflow can be invoked using REST and gRPC APIs or by publishing an event to a queue that Conductor is listening to. Once invoked, Conductor will drive the execution as defined by scheduling tasks which are allocated to your micro services that are listening to Conductor for performing work. Using the API interfaces or through the Conductor UI, you can check the status of running workflows and quickly zoom in on their status and errors. This cuts down debugging of distributed applications from hours to minutes, especially when there are millions of workflows running every day.
Another key aspect of Conductor is the durability of workflows it executes. You can have workflows that are in a running state for months or even years that need to only occasionally execute tasks (e.g. billing a subscriber at the beginning of each month). Conductor will keep the workflow state exactly where it is waiting even in the event of workers for the tasks going down or are upgraded. This allows developers to upgrade microservices while having workflows in-flight!
Furthermore, with Conductor you can innovate fast without having to manage complex rollouts. If your business logic changes, you can update the workflow definition to a new version and gradually phase that in by having a subset of invocations to use the new version. Conductor will concurrently execute both versions, thereby removing the risk of a large blast radius if anything were to go wrong in the new version.
