Skip to content

Architecture Deep Dive

API server, scheduler, cron loop, and worker reaper all run in a single process. No separate queue infrastructure. PostgreSQL is the only external dependency.

orch8-serverREST API (Axum)Scheduler (100ms)Cron Loop (10s)HandlerRegistryWorker Task Reaper (30s)StorageBackend (Postgres impl)PostgreSQLNode / Python / GoWorkers

Crate structure

The engine is a Rust workspace with five crates:

  • orch8-typesShared domain types — IDs, instance states, block types, signals, context, config
  • orch8-engineCore execution logic — scheduler, evaluator, handlers, signals, templates, recovery, metrics
  • orch8-storageDatabase abstraction trait + PostgreSQL implementation
  • orch8-apiREST API layer — health, sequences, instances, metrics endpoints
  • orch8-serverApplication entry point — config loading, server startup, graceful shutdown

Snapshot-based execution

Unlike Temporal (which replays event history on every wake-up), Orch8 saves a state snapshot after each step. Resuming is a single database read — O(1) regardless of how many steps ran before.

AspectTemporalOrch8
Resume mechanismReplay entire historyRead last snapshot
Coding rulesNo Date.now(), no Math.random()Write normal code
State visibilityCustom query handlersREST API — GET /instances/{id}
Code changesRequire patched() markersApply immediately to new instances
Payload limits64KB per eventNone (Postgres rows)
TestingNeeds running serverSame binary, same code

Two execution paths

Timer-driven (scheduling)

For campaign sequences where steps fire on a schedule. Every tick (default 100ms), the engine claims due instances using SELECT ... FOR UPDATE SKIP LOCKED, ordered by priority then fire time. For each instance it checks rate limits and either fires the handler or defers to the next available window.

Event-driven (orchestration)

For workflows with parallel steps, races, loops, and signals. When a step completes or a signal arrives, the engine evaluates the execution tree and immediately runs the next block — no timer delay.

Technology stack

LanguageRustPerformance, memory safety, no GC pauses
StoragePostgreSQL + SQLiteProduction on Postgres, zero-dep local dev on SQLite
APIREST + gRPC + SSEaxum-based REST; Tonic gRPC; SSE via /instances/{id}/stream
Plugin runtimeWasmtime (WASM)Sandboxed handler execution; wasm:// dispatch prefix
Message queueNATS (optional)async-nats subscriber; config-driven trigger subjects
File eventsnotify crateCross-platform fs-event trigger; recursive watch support
MetricsPrometheusCounters, histograms, gauges at /metrics
LoggingStructured JSONConfigurable level, tracing-based
DeploymentSingle binary + DockerMinimal ops

Storage abstraction

The engine uses a StorageBackend trait that abstracts all database operations. The PostgreSQL implementation is the production backend. The trait is designed so additional backends can be added.