Workers

The processes that do the actual work in an iii system.

What a Worker is

Workers are what actually do things in an iii system. Every category of capability is built as a Worker: queues, scheduling, sandboxing, observability, agents, business logic, devices, and even code executing in a browser.

Specifically, a Worker is a process that connects to the Engine over WebSocket and announces a set of Functions it can run and Triggers to register. Once connected, those Functions are invocable from anywhere in the system and those Triggers will respond to their events without per-pair integration code between the caller and the Worker.

The Worker concept is intentionally narrow. A Worker is not a microservice, a job runner, or a sidecar. It is a participant in the Engine’s live registry that contributes Functions and Triggers. Whether the Worker is a long-lived process serving thousands of invocations per second or a short-lived process that connects, registers, runs once, and shuts down, the Engine treats it the same.

Worker isolation

Workers are intended and designed to be independent processes. One Worker crashing does not affect others. The Engine connects to each Worker over a separate WebSocket and routes invocations only to Workers that are currently connected. A crash, restart, or network partition affecting one Worker does not propagate to the others. The crashed Worker’s Functions and Triggers drop out of the routing table on disconnect, and every other Worker keeps serving.