DOSS powers its ERP workflow engine with Restate

DOSS is an AI-native ERP platform that helps businesses manage procurement, inventory, orders, fulfillment, and finance in real time. A substantial part of the offering is its workflow engine: customers describe workflows in a custom DSL to connect data inside the ERP with external integrations and to drive operational flows such as managing inventory and sales orders.

DOSS uses Restate to run that workflow engine. Their DSL interpreter is implemented on top of Restate, giving every workflow durable execution, recovery, and observability without DOSS having to build any of that themselves.

Before Restate: Architecture & Challenges

Before Restate, DOSS ran their workflow engine on a combination of BullMQ for queuing and Postgres for workflow state. The DSL interpreter was wired on top of this stack, and the team had built their own custom logic for transitions, retries, and recovery.

Over time the cost of operating that system became hard to justify:

• Lack of observability: The team had built an interface on top of Postgres to see the current snapshot of a workflow's state, and they could inspect the queues. But this was not enough for easy debugging: there was no clear way to see current retries, the actual error a step was failing on, or why a workflow was stuck.
• Scale limits from the queue: BullMQ doesn’t provide built-in support for automatically scaling workers based on queue backlog. Restate, on the contrary, natively works with Cloud Run’s autoscaling parameters, making it much easier to handle fluctuating or bursty workloads efficiently.
• Operational toil: Killing a single workflow meant running multiple manual queries across the queue and database, and disabling the workflow while the cleanup ran, making it temporarily unavailable to customers.

The team wanted to move to an off-the-shelf solution so it could focus on shipping the ERP features that actually differentiate DOSS, instead of a homegrown workflow orchestrator.

Why Restate?

DOSS evaluated alternatives before choosing Restate. They picked Restate for its:

• Resiliency and consistency: Rather than continuing to maintain durability, retries, and state persistence in-house, DOSS wanted a system that solved those problems out of the box so their team could focus on the ERP business logic.
• A programming model their DSL could map onto: The DSL interpreter could be expressed naturally on top of Restate's primitives — durable handlers, service calls, and deterministic concurrency — without re-architecting the engine.
• Detailed observability: Restate gives them visibility into running workflows, retries, and failures by default.

The Results

DOSS now runs their workflow engine on Restate Managed Cloud. Their DSL interpreter is implemented as a Restate service that interprets each workflow step and uses Restate's context to make downstream calls, with the interpreter recursively invoking itself to walk through the DSL.

The DSL primitives of their workflow engine mapped nicely onto Restate's building blocks. It took two weeks to migrate their DSL onto Restate. Giving them now time to focus on adding features their customers care about.

The Restate features they rely on most heavily today:

• Durable Execution: Replaces the custom transition tracking, retry handling, and state persistence.
• Virtual Objects: The DSL interpreter is built as a Virtual Object that drives the workflow's downstream calls. This is the core building block their DSL maps onto.
• Deterministic concurrency (combinators): Used extensively to express concurrent steps inside workflows while preserving deterministic replay.
• Operational simplicity: Operations like canceling, killing or rerunning a workflow is now a single action.