Routing Desktop Workflows Across a Pool of VMs

When a workflow execution request arrives, the orchestration layer needs to answer a series of questions very quickly:

The Questions the Routing Layer Must Answer

Which VMs are available? Each VM in the pool runs a lightweight service that maintains a connection to the platform and reports its status: idle, busy, or offline.

Which VM is right for this workflow? Different workflows may target different applications. The routing layer maps workflow types to compatible machines and picks one that is both compatible and idle.

Is the VM ready? Being idle is not enough. The target application needs to be open, logged in, and on the right screen. A health check confirms this before the automation starts.

What if everything is busy? The request goes into a queue. When a VM finishes its current work and passes the health check, it picks up the next queued request.

What if the VM fails mid-execution? The platform detects lost connections through heartbeat monitoring. It marks the execution as failed, and optionally retries on a different VM. The caller gets a failure notification with the full context of what happened.

What about concurrent requests for different users? Desktop applications are single-tenant. One VM can only run one automation at a time. The pool needs to be sized for peak concurrent load, with the ability to scale when demand exceeds capacity.

The Architecture Pattern

None of this is conceptually novel. It is standard distributed systems engineering: load balancing, health checks, queue management, failover, capacity planning. The novelty is applying it to an environment where the "servers" are Windows desktops running legacy software and the "API" is a mouse and keyboard.

The architecture pattern is always the same: a thin API layer that accepts requests, a routing layer that manages the VM pool, and a desktop service on each VM that executes workflows and reports results. The complexity lives in the health checking, session management, and failure recovery. That is where production systems differ from demos.