Why We Built Our Workflow Engine in Rust (And What That Means for Enterprise Performance)

The Workflow Engine Is the Heartbeat of the Enterprise

Every enterprise process is a workflow. Employee onboarding: 47 steps across HRMS, IT provisioning, finance, and facilities. Purchase order approval: 8 steps across procurement, budget validation, and management sign-off. Incident response: 12 steps across detection, triage, remediation, and post-mortem. Customer contract renewal: 15 steps across sales, legal, finance, and fulfillment.

When you run 19 enterprise applications on a unified control plane, every cross-application process routes through the workflow engine. It is not a peripheral system. It is the central nervous system. If the workflow engine is slow, every process is slow. If it pauses, the organization pauses. If it drops executions under load, business processes fail silently.

This is why we built OwnFlow in Rust.

The Problem With Existing Workflow Engines

Most enterprise workflow engines are built on the JVM (Camunda, Activiti), Node.js (n8n, Temporal's SDK layer), or Python (Airflow, Prefect). These are excellent languages for many use cases. Workflow execution at enterprise scale is not one of them.

The fundamental issue is garbage collection. The JVM, Node.js, and Python all use garbage collectors that periodically pause execution to reclaim unused memory. In a web application, a 10-millisecond GC pause is invisible to the user. In a workflow engine processing thousands of executions per second, a 10-millisecond GC pause means hundreds of workflow nodes stall simultaneously.

For human-driven workflows — a manager approving a purchase order — this latency is irrelevant. The human takes 30 seconds to read the request. A 10-millisecond engine pause is lost in the noise.

For AI-agent-driven workflows — an agent processing hundreds of decisions per second — a 10-millisecond pause is a catastrophe. The agent's context window has moved on. The data it was operating on may have changed. The business condition it was evaluating may no longer hold.

Enterprise workflow engines were designed for human speed. AI agents operate at machine speed. The engine must match the agent.

Why Rust

Memory Safety Without Garbage Collection

Rust achieves memory safety through its ownership system — a compile-time mechanism that tracks which code owns which memory and when that memory can be freed. There is no runtime garbage collector. Memory is allocated when needed and freed deterministically when the owning scope ends.

For a workflow engine, this means zero GC pauses. Ever. A workflow node that takes 0.3 milliseconds to execute will take 0.3 milliseconds every time. Not 0.3 milliseconds most of the time and 12 milliseconds when the GC decides to run. Predictable latency is not a nice-to-have for enterprise infrastructure. It is a requirement.

Predictable Latency

OwnFlow achieves sub-millisecond execution for individual workflow nodes. A conditional branch evaluation: 0.08ms. A data transformation: 0.15ms. A permission check against the control plane: 0.22ms. An audit log write: 0.18ms. These numbers are consistent under load because there is no runtime that can preempt execution for memory management.

When a workflow has 20 nodes, the total execution time is the sum of the node times plus inter-node overhead. A 20-node workflow completes in under 5 milliseconds. In Java, the same workflow might complete in 5 milliseconds on a good run and 50 milliseconds when GC intervenes. In Node.js, the event loop can introduce similar unpredictability under high concurrency.

The Concurrency Model

OwnFlow uses Tokio, Rust's asynchronous runtime, for concurrent workflow execution. Tokio's work-stealing scheduler distributes tasks across all available CPU cores with minimal overhead. When a workflow node is waiting on I/O — a database read, an API call, a message queue publish — the runtime schedules another workflow's node on the same thread. No thread is ever idle while work is available.

This is not unique to Rust. Node.js has an event loop. Java has virtual threads (Project Loom). But Rust's zero-cost abstractions mean the async/await machinery compiles to state machines with no heap allocation per future. Each suspended workflow node costs bytes of stack space, not kilobytes of heap. This is what allows OwnFlow to hold 100,000+ concurrent workflow executions in memory without pressure.

The Architecture of OwnFlow

OwnFlow is structured as a three-layer system: the definition layer, the execution layer, and the persistence layer.

The definition layer parses workflow definitions from a declarative DSL into an in-memory directed acyclic graph (DAG). Each node in the DAG is a typed workflow step — condition, transformation, action, approval gate, or sub-workflow invocation. The DAG is validated at parse time: type checking on all data flows, cycle detection, and permission verification against the control plane.

The execution layer is where Rust's advantages are most visible. The execution engine maintains a priority queue of runnable nodes across all active workflow instances. The Tokio runtime pulls nodes from the queue and executes them on a thread pool. Each node execution is a self-contained async function that receives an immutable reference to the workflow context, performs its operation, and returns a result that the engine uses to determine the next node(s) to schedule.

The persistence layer handles durability. Every state transition — node start, node complete, branch taken, error raised — is written to an append-only event log. If OwnFlow crashes and restarts, it replays the event log to reconstruct the exact state of every in-flight workflow. No execution is lost. No node is executed twice. This is event sourcing at the workflow engine level.

What 50K Executions Per Second Means in Practice

Fifty thousand workflow executions per second sounds like a benchmark number. Here is what it means in operational terms.

A large enterprise might have 10,000 employees, each triggering an average of 20 workflow steps per day through their normal work — approvals, status changes, assignments, escalations. That is 200,000 workflow steps per day, or roughly 2.3 steps per second during business hours. A Node.js-based workflow engine handles this easily.

Now add AI agents. A single agent processing support tickets can trigger 500 workflow executions per minute — reading the ticket, classifying it, checking SLAs, routing it, updating the customer, logging the action. Ten agents running concurrently produce 5,000 executions per minute. A hundred agents — which is where enterprises are heading — produce 50,000 executions per minute.

At peak load, with burst processing, agent-driven workflows can spike to thousands of executions per second. A year-end closing process where agents reconcile thousands of transactions simultaneously. A security incident where agents isolate affected systems, revoke credentials, and notify stakeholders in parallel across every application.

These are not theoretical scenarios. They are the operational reality of AI-native enterprise infrastructure. The workflow engine must handle them without degradation.

The Rust Advantage for Long-Running Processes

Enterprise workflows are not always fast. Some run for days or weeks — a multi-stage procurement approval, a compliance review, an employee relocation process. The workflow engine must maintain state for thousands of long-running workflows while simultaneously executing thousands of short-lived ones.

In garbage-collected languages, long-running workflows create memory pressure. Each suspended workflow holds references to its context data, preventing garbage collection. Over time, the heap grows. GC pauses get longer. Eventually, the engine needs a restart to reclaim memory.

Rust's ownership model eliminates this entirely. When a workflow is suspended waiting for an approval, its state is serialized to the persistence layer and its memory is freed. Not freed by a garbage collector at some future time. Freed immediately, deterministically, when the serialization completes. The engine's memory footprint is proportional to the number of actively executing workflows, not the total number of in-flight workflows.

This is why OwnFlow can maintain 500,000 in-flight workflows (most suspended, waiting for human or external input) while executing 50,000 active workflows per second, on a single 8-core machine with 16 GB of RAM.

The Trade-Offs

Rust is not without costs. Compile times are slower than Go or Java. The learning curve is steeper. Hiring Rust engineers is harder than hiring Java or Node.js engineers. We made this trade-off deliberately.

The workflow engine is a foundational component that will run for years. It will be maintained by a small, specialized team, not a rotating cast of generalists. The compile-time cost is amortized over millions of executions. The learning curve is paid once. The performance benefit compounds every second the engine runs.

For application-level code — the UI, the API layer, the business logic modules — we use TypeScript. It is the right tool for those layers. For the workflow engine — the system that must never pause, never degrade, and never lose an execution — Rust is the right tool. Using the same language for everything is a convenience. Using the right language for each component is engineering discipline.

We don't use Rust because it's fashionable. We use it because the workflow engine is the one component where predictable performance is a non-negotiable requirement.

What This Means for Enterprises

If you are evaluating enterprise platforms, ask about the workflow engine. Not the visual designer. Not the template library. The engine itself. What language is it built in? What are its latency characteristics under load? How does it handle garbage collection pauses? What is its maximum throughput on your hardware?

The workflow engine is the component that will determine whether your AI agents can operate at machine speed or are throttled to human speed. It is the component that will determine whether your year-end close takes minutes or hours. It is the component that decides whether your enterprise can run 10 agents or 1,000.

We built OwnFlow in Rust because we are building infrastructure for the AI-native enterprise. That enterprise will run hundreds of agents, processing tens of thousands of workflow executions per second, with requirements for deterministic latency and zero-downtime operation. The workflow engine cannot be the bottleneck. With Rust, it won't be.