Clustering

Rylee Soll Updated 2026-07-27 8 min read 1,483 words

features clustering scalability Advanced

Without clustering, a single Workflow Engine server is a single point of failure. If it goes down, timers stop, processes pause, and automated transitions halt until the server is restored. Scaling to higher throughput means vertical scaling - more CPU, more memory - which has hard limits and diminishing returns.

Clustering is the ability to run multiple Workflow Engine runtime instances across separate servers, all connected to the same persistence database, with no external coordinator or message broker.

With clustering, you add or remove servers without downtime. If one server fails, the remaining servers continue processing timers and executing commands. Timer execution is coordinated through the database itself - no leader election, no Redis, no ZooKeeper. For example, three application servers running in a cluster all poll for due timers every polling interval. The first instance to acquire a database-level lock on a timer record executes it; the other instances skip that timer.

What it is

Think of clustering as a team of workers sharing a single to-do list on a shared whiteboard. Each worker checks the list for new items, writes their name on the one they are picking up, and works through it. If a worker leaves, the others keep going. Nobody needs to tell the team who the leader is - the whiteboard (database) handles coordination naturally.

Workflow Engine clustering is database-backed. All runtime instances read and write the same process instances, schemes, and timers in the shared persistence store. The mode is configured at runtime initialization:

• AsSingleServer - Default mode. One runtime instance owns all timers and process execution. Uses an in-process timer loop that polls the database without distributed locking. Suitable when the application runs one instance.
• AsMultiServer - Cluster mode. Each runtime instance competes for timer work using database-level locking. Each instance polls for due timers at a configurable interval, acquires a lock on the timer record, and executes it. No single point of failure. Dead runtime instances are detected through missing heartbeat signals in the WorkflowRuntime table.

The runtime does not require sticky sessions, shared file systems, or distributed caches. Each instance is stateless with respect to runtime data - all state lives in the persistence database.

For developers: AsMultiServer() creates a MultiServerServiceRunner and a MultiServerTimeManager. Timer polling interval, lock timeout, heartbeat interval, and maximum instance count are configurable through MultiServerSettings. Each runtime instance must have a unique ID (set via the WorkflowRuntime(Guid) or WorkflowRuntime(string) constructor). Heartbeat signals are written to the WorkflowRuntime database table. See Multi-Server Mode for configuration details and Single-Server Mode for the non-clustered alternative.

Why it matters

Clustering delivers these outcomes:

• No single point of failure - If one server in the cluster fails, the remaining instances pick up its work. Timer execution, process completion, and automated transitions continue without interruption. The dead runtime's running processes are restored on surviving nodes via heartbeat-based detection.
• Horizontal scale-out without infrastructure complexity - Add throughput by adding more application servers, not by upgrading hardware. The database-backed coordination model requires no Redis, no message broker, no ZooKeeper, no load balancer with sticky sessions. Each instance is identical - add or remove them by starting or stopping the process.
• Rolling updates with zero downtime - Deploy a new version of the application one server at a time. The cluster remains operational throughout the update. Running process instances are not interrupted - they continue on the remaining instances and are handled by the updated instances once they rejoin.
• Linear cost model - Each additional server improves throughput proportionally. The shared database is the only resource that needs capacity planning. Workflow Engine supports SQL Server, PostgreSQL, MySQL, MongoDB, and Oracle as the coordination database.

Who it is for

Evaluator (CEO, CTO, PM): Clustering removes the single-server bottleneck from production deployments. If you anticipate growth in process volume or need guaranteed uptime for workflow operations, clustering provides both - without adding infrastructure services to manage. The database-backed approach keeps operational complexity low: your team already manages databases.

Developer: You configure clustering by calling runtime.AsMultiServer(settings) on each runtime instance. Each instance requires a unique ID. All clustering settings - polling interval, heartbeat interval, lock timeout - are in MultiServerSettings. See Multi-Server Mode for the configuration reference and Failover and Restore for process recovery behavior.

Enterprise architect: Clustering uses the existing database for coordination, which fits into standard enterprise database backup, replication, and disaster recovery procedures. Runtime instances are stateless and can be deployed behind round-robin load balancers. Process-runtime associations are tracked in the WorkflowRuntime table, enabling targeted restore when a specific instance fails.

When to use it

Use clustering when a single server cannot meet your availability or throughput requirements. Typical examples:

• Production deployment with uptime requirements - Your workflow system must remain operational during server maintenance, updates, or failures. A three-node cluster ensures that no single server outage stops process execution. The remaining nodes assume the load automatically.
• High-throughput process automation - Your business processes generate thousands of process instances per hour with automated timer-driven transitions. A cluster spreads timer execution across multiple servers, increasing aggregate throughput beyond what a single instance can handle.
• Multi-region or multi-datacenter deployment - Runtime instances in different data centers all point to the same shared database. The database-backed coordination model works across network boundaries without additional messaging infrastructure. Latency between instances affects timer polling responsiveness but does not break coordination.
• Rolling upgrade without process interruption - You need to deploy a new version of the workflow application without stopping running processes. With clustering, stop each instance one at a time, update it, and restart. The cluster operates at reduced capacity during the update but never fully stops.

How it compares

The table below compares Workflow Engine's database-backed clustering approach with alternatives that require external coordination services.

Frequently asked questions

What infrastructure do I need for clustering?

A shared database accessible from all cluster nodes. Workflow Engine supports SQL Server, PostgreSQL, MySQL, MongoDB, and Oracle as persistence providers. Each cluster node runs a standard ASP.NET Core application with the Workflow Engine NuGet package. No additional services - message queues, load balancers with sticky sessions, or distributed caches - are required.

How do timers coordinate across cluster nodes in multi-server mode?

Each runtime instance polls the database for due timers at a configurable interval (default 1000 ms in MultiServerSettings). When an instance finds a due timer, it acquires a database-level lock on that timer record. Only the instance holding the lock executes the timer. The polling interval and lock timeout prevent duplicate execution even with many nodes. The first instance to lock wins; others skip and continue polling.

Do I need a specific license for clustering?

Clustering in multi-server mode requires a commercial license. Workflow Engine Free supports AsSingleServer mode only. See Workflow Engine Editions for the full comparison.

What happens when a server in the cluster fails?

The surviving instances detect the failure through missed heartbeat signals. The MultiServerServiceRunner on each survivor checks the WorkflowRuntime table for instances that have not sent a heartbeat within the configured timeout. When a dead instance is detected, one survivor acquires a lock on the dead instance's record and restores all process instances that were associated with it. Other survivors detect the lock and skip, preventing duplicate recovery. See Failover and Restore for the detailed flow.

Can I limit the number of cluster nodes?

Yes. Set MaxNumberOfInstances in MultiServerSettings. On startup, the MultiServerServiceRunner counts active runtime instances in the WorkflowRuntime table. If the limit is reached, the new instance waits and retries according to StartStatusCheckPauseInterval and StartStatusCheckAttemptCount. This prevents license violations when running under a fixed-instance license.

See also

• Workflow Engine Editions

  Which license level includes clustering support.