WebAssembly Worker Chassis

SpectraFlux is an ultra-lean WebAssembly chassis for asynchronous workloads.

Run high-density WebAssembly "Fluxcell" workers focused entirely on your business logic. SpectraFlux provides an ultra-minimal operational footprint with instantaneous hot-swap deployments, built-in durable idempotency steps, causal order guards, and pooled PostgreSQL transactions.

Open-Source Appliance · Zero Application Pollution · Postgres Standard

Event Sources:NATS JetStream·Apache Kafka·Redpanda·Redis Streams
< 0.8ms Cold Start
Wasmtime instance pooling
80/20 Durable Steps
ctx.step side-effect memoization
16MB to 4GB RAM
Dense pooling to heavy batch
Chassis Architecture & Execution Topology
SpectraFlux WASM chassis execution pipeline wireframe full resolution
Click outside or press ESC to dismisswasm32-wasip1 instance pooling · sub-millisecond execution
The BYOW Write Path

Need to bring a worker for SpectraGQL? Try SpectraFlux

SpectraGQL coordinates your microservices with CQRS at wire speed, but its write path relies on Bring-Your-Own-Worker (BYOW). Instead of writing and maintaining hundreds of lines of custom consumer daemon boilerplate, connection pools, and retry logic, drop in SpectraFlux. Write pure mutation logic in sandboxed WebAssembly fluxcells while the chassis handles the rest.

SpectraFlux WASM sandbox and host ABI wireframe schematic

Monotonic HLC causality guards. 80/20 durable step memoization. Pooled RAII PostgreSQL transactions with auto-rollback on Drop.

< 0.8msMetric #1

Wasmtime instance pooling

< 25MBMetric #2

Zero-compiler container

50k+ ops/sMetric #3

Per-core sustained dispatch

Engine Capabilities & Architecture Invariants
Pure mutation logic: write the business handler, skip the broker plumbing
80/20 durable step idempotency (ctx.step)
Standalone broker-native: connects directly to NATS JetStream, Kafka, Redpanda, or Redis/Valkey Streams
Zero crypto overhead: paired with SpectraGQL, fluxcells execute with pre-verified claims
PostgreSQL RAII transactions with auto-rollback on Drop
Dynamic zero-downtime deployer API (< 200ms)
50 isolated micro-workers in 1 container
Architectural Philosophy

The 80/20 Idempotency Story

Why real-world mutations break on retries, why you can't architecturally side-step dependent state with multiple queues, and how SpectraFlux solves 80% of distributed durability with 20% of the complexity.

The Problem Space

A mutation is almost never a single atomic step

Most developers think idempotency just means: "don't charge my credit card twice." But in real enterprise systems, an asynchronous mutation is an orchestration of mixed internal database writes and external third-party APIs:

STEP 01ACID Tx
Check & Reserve
Reserve stock in PostgreSQL within an active transaction.
STEP 02External API
Stripe Charge
Authorize card via third-party HTTP call with financial consequence.
STEP 03ACID Tx
Dependent Commit
Commit order with Stripe authorization token. Auto-rolls back on fault.
STEP 04External API
Provision License
Generate tenant workspace or cryptographic API credentials.
STEP 05Webhook / SMS
Notify Customer
Dispatch SMS confirmation via Twilio and confirmation email.
Architectural NuanceWhy you can't architecturally side-step this by "splitting into multiple queues"
▼

Developers often try to avoid idempotency by suggesting: "Just put the Stripe payment on one queue and the database write on another!"

Except Step 3 (PostgreSQL order commit) is causally dependent on Step 2 (Stripe authorization token). If Stripe declines the card, the database write must never happen. If Stripe succeeds, the database write must record that exact transaction token in the same row.

When internal state transitions depend on external API outputs, you cannot decouple them into independent fire-and-forget queues. You have an ordered pipeline inside a single logical unit of execution. If your worker pod crashes at Step 4, a naive broker redelivery will re-execute Step 2—charging the customer twice unless step results are memoized.

The Solution in Code

Standard Procedural TypeScript with ctx.step

No complex workflow deterministic state engines. No Cassandra cluster tax. Just clean business logic.

< 50µs Re-Entry CacheRAII SQL Auto-Rollback
checkout_cell.tswasm32-wasip1
import { Context, Database } from "@spectraflux/sdk";

export async function handleCheckout(ctx: Context, cmd: CheckoutCommand) {
  // STEP 1: Idempotent External Side-Effect (Memoized in host Kevy storage)
  // On broker redelivery after crash, returns in < 50µs WITHOUT re-charging!
  const charge = await ctx.step("stripe_charge", async () => {
    return await stripe.charges.create({
      amount: cmd.amountCents,
      currency: "usd",
      source: cmd.paymentToken,
      idempotency_key: `checkout_${cmd.orderId}`
    });
  });

  // STEP 2: ACID Relational Commit (Pooled PostgreSQL)
  // Causally dependent on Step 1 output (charge.id).
  // RAII Guard: If the worker panics or times out, pending SQL rolls back instantly.
  const tx = await Database.beginTx();
  await tx.execute(
    "INSERT INTO orders (id, user_id, charge_id, total, status) VALUES ($1, $2, $3, $4, $5)",
    [cmd.orderId, cmd.userId, charge.id, cmd.amountCents, "PAID"]
  );
  await tx.commit();

  // STEP 3: Out-of-Band Downstream Event Dispatch
  await ctx.publish("orders.confirmed", { orderId: cmd.orderId, chargeId: charge.id });
}
Saga Architecture Trade-Offs

The 100/100% Saga Model vs. SpectraFlux 80/20

Why run heavy distributed saga engines when 90% of your mutation workloads execute in under 5 seconds?

The 100/100% Heavy Saga Model

Temporal / Cadence / Heavy Event-Sourcing

Complex & Heavy

Compiled into full event-sourced deterministic state machines where every variable assignment and function call is logged to a central orchestration cluster.

Infrastructure Footprint:Dedicated multi-node cluster + Cassandra/DB + daemons
Step Latency Tax:50ms – 200ms per step (cluster round-trips)
Code Constraints:Strict determinism (no standard Date.now, no random)
Deployment Friction:NonDeterministicWorkflowError on code changes
Primary Strength:Multi-week human-in-the-loop approval workflows

SpectraFlux 80/20 Sweet Spot

ctx.step Memoization + RAII PostgreSQL

20% Complexity

90% of business mutations execute in 100ms to 5 seconds. SpectraFlux memoizes external side-effects locally and rolls back dirty SQL transactions automatically on failure.

Infrastructure Footprint:Zero cluster tax (embedded in < 25MB chassis)
Step Latency Tax:< 50 microseconds (cached KV retrieval on retry)
Code Constraints:Standard procedural code: wrap side-effects in ctx.step
Deployment Friction:Instant hot-swap via API (< 200ms, zero downtime)
Primary Strength:Zero duplicate charges or partial writes on broker retry
Transparent Boundaries

The 20% We Do Not Solve

Solving challenging problems elegantly means knowing where to limit scope. If your requirements fit any of these four criteria, SpectraFlux is not the right solution:

01. Multi-Day Sagas
Human Approval Loops
Workflows that must pause for 14 days waiting for an underwriter's email confirmation. Fluxcells execute from milliseconds up to 5-minute batch jobs. For multi-week pauses, use Temporal.
02. 20-Service Rollbacks
Massive Distributed Sagas
Complex two-phase compensation trees spanning 20 different vendor APIs where failure at step 19 rolls back steps 1 through 18 across third-party platforms.
03. Stack Hibernation
Call-Stack Serialization
Fluxcells do not freeze memory to disk and resume next Tuesday. When execution completes or times out, the WASM memory sandbox is completely recycled.
04. Heavy C / PyTorch Models
Unsandboxed GPU Drivers
Background workers requiring 5 GB PyTorch tensors or proprietary CUDA Linux drivers that cannot compile to WASI. Run those in standard Docker containers.
Resource Flexibility

From 16MB dense micro-workers to 4GB heavy domain modules

Fluxcells are not restricted to one mutation per file. A single fluxcell can subscribe to multiple topics (["orders.checkout", "orders.refund", "orders.cancel"]) or export multiple REST routes (POST /verify, GET /session), forming a cohesive domain module.

In 32-bit WebAssembly (wasm32-wasip1), linear memory reaches up to 4 GB per cell. SpectraFlux supports lightweight 16MB–64MB transaction cells with pre-warmed instance pooling side-by-side with 4GB batch workers using virtual memory demand paging.

< 0.8 ms
Dense Instance Pooling
Lightweight 16MB–64MB cells pre-allocated in memory slots for sub-millisecond cold starts.
Up to 4 GB
Dedicated Batch Workers
Heavy JSON transforms, PDF generation, or embedded WASM SQLite using OS worker thread offloading.
Multi-Route
Cohesive Domain Modules
Group entire bounded contexts into one deployable cell with multiple broker topics and HTTP routes.
Epoch Watchdogs
Hardware-Isolated Sandboxes
Runaway loops and memory leaks in one cell are terminated without affecting peer workers in the same chassis.
Chassis & Storage Architecture

Hardware-Isolated Chassis & Decoupled Storage

SpectraFlux couples a hardware-isolated WebAssembly execution chassis with strictly partitioned storage tiers. Host ABI security boundaries guarantee that guest fluxcells cannot tamper with chassis operations, while PostgreSQL standardizes ACID relational state.

Runtime Foundation

The Wasmtime Execution Chassis

< 25 MB Container

A high-velocity, single-binary appliance built on Wasmtime. Eliminates container sprawl by running dozens of micro-workers inside one memory space with hardware-enforced isolation.

< 0.8ms Pooling
Pre-allocated instance memory slots for sub-millisecond cold starts.
Up to 4GB per Cell
Dedicated worker offload with OS virtual memory paging for heavy tasks.
Epoch Watchdogs
Hardware-level tick counter kills runaway loops without dropping streams.
Zero Compiler Bloat
Container bundles no rustc, cargo, or git. Immutable wasm binaries only.
Guest Workers

Domain-Rich FluxCell Sandboxes

wasm32-wasip1

Fluxcells are compiled WebAssembly modules representing bounded contexts. A single cell can subscribe to multiple event topics and serve HTTP REST routes within one cohesive module.

01.
Host ABI Bindings:Guest code communicates with host databases and storage solely through typed, secure WASI imports.
02.
Dynamic Hot-Swapping:Deploy new bytecode via POST /_flux/deployer/upload in < 200ms with zero downtime and atomic staging.
03.
Zero Application Pollution:Chassis code remains 100% generic open source. All business schemas and secrets stay inside guest fluxcells.
Decoupled Storage Tiers

Strict Storage Partitioning & Linker Boundaries

internal-storageFramework Scope

Chassis Internal Storage

Engine: kevy://embedded

Dedicated exclusively to chassis framework operations: Saga state checkpoints, magic-link OTP tokens, session cache, and domain traces. Host ABI bind_host_checkpoint writes strictly here. Guest cells cannot read or modify this space.

✓ Host ABI Boundary Enforced
fluxcell-storageGuest Application Scope

Fluxcell Application State

Engine: kevy:///data/fluxcell-storage.kevy

Dedicated exclusively to guest fluxcell application state, KV operations (kv_store), and Redis wire protocol commands (host_redis). Supports persistent volume mounts with fail-safe local dev fallback to ./data/.

✓ Host ABI Boundary Enforced
relational-dbProjections & ACID

Relational Storage (Postgres or Bust)

Engine: PostgreSQL Standard

SpectraFlux standardizes exclusively on PostgreSQL for persistent relational storage to eliminate dialect fragmentation and avoid container bloat. Database migrations are plain SQL files embedded at compile time (include_str!).

✓ Host ABI Boundary Enforced
Deployment & Lifecycle

Deploy Micro-Workers in Milliseconds

Fluxcells compile in CI/CD to immutable wasm32-wasip1 binaries and hot-swap into the live running chassis via API in < 200ms—with zero container restarts and zero dropped broker messages.

Interactive Lifecycle DiagramHot-Swap Flow

Dynamic Deployment & Broker Topic Wiring

Click any phase to inspect how topics are declared, authenticated, dynamically wired to broker streams, and hot-swapped in 184µs.

Zero Container Restarts · 184µs Swap
1. CI/CD BUILD TARGETwasm32-wasip1Immutable Bytecode ArtifactOUTPUT: orders.wasm342.6 KB (Optimized)TOPIC DECLARATION (ABI)TOPICS = ["orders.checkout","orders.refund"]; mount: "/orders"✓ Zero compiler in container2. DEPLOYER INGESTPOST /_flux/deployer/uploadBearer Token Guard (<200ms)AUTH: DeployGuardConstant-time token verifyHOST ABI VALIDATION✓ WASI byte check: OK✓ Linker boundary: OK✓ Checkpoints isolated✓ State: Staged -> Active✓ Sub-millisecond staging3. CHASSIS ROUTER184 µs Hot-SwapDynamic Radix & Topic WireBROKER TOPIC BINDINGGroup: orders-v2Stream: NATS / Kafka / RedisDYNAMIC RADIX SWAP/orders -> Cell#orders_v2Drained in-flight: 0 msgsDropped messages: 0✓ Zero dropped stream messages4. WASM SANDBOX< 0.8ms PoolingPre-Warmed Execution SlotINSTANCE POOLSlot#07 (16 MB)Scales up to 4 GB VMem80/20 DURABILITYctx.step: <50µs re-entryPostgres: RAII pooled TxEpoch Watchdog: OK✓ Automatic SQL rollback
Admin Telemetry Drawerhttp://chassis:8000/admin

Live Fluxcell Telemetry & Security Controls

Deployer: ACTIVE
Lockdown: STANDBY
Cell IdentifierStateMemory / LimitCold StartAttached Routes / TopicsInvocations
orders_workerv2 (184µs swap)
ACTIVATED18.2 MB / 64 MB< 0.4 ms["orders.checkout", "orders.refund"]142,850
magiclink_authv1
ACTIVATED12.1 MB / 32 MB< 0.3 msPOST /verify, POST /send-otp89,402
nightly_batchDedicatedWorker
STANDBYScales to 4 GB (VMem)On Demandcron(0 2 * * *)1,420
Chassis Footprint: 22.4 MB·Zero Container Restarts
✓ Host ABI Bound · 0 Dropped Stream Messages
Architectural Alternatives

How SpectraFlux compares to the alternatives

Every backend architecture makes deliberate trade-offs. Here is why teams choose SpectraFlux over container workers, general WASM frameworks, or heavy workflow orchestrators.

Container Workers

Node.js / Go / BullMQ / KafkaJS

Legacy Default

Traditional background worker containers

Cold Start:2 - 10 seconds
Memory:150MB - 800MB per worker
Causality & Order:Naive ACK/NACK; out-of-order writes corrupt state
Durability:Manual code; retries repeat external side effects
Deploy Time:Slow (rebuild Docker, push, roll Kubernetes pods)
Complexity:High container sprawl (50 workers = 50 pods)

General WASM

Fermyon Spin / WasmCloud

HTTP / Actor Focused

Serverless WASM HTTP & actor lattices

Cold Start:< 1ms
Memory:< 25MB
Causality & Order:No built-in HLC causality or partition ordering
Durability:No native step memoization (ctx.step)
Deploy Time:Fast WASM deploy, but requires SpinKube / lattice
Complexity:High operational abstraction (actors, lattices)

Heavy Orchestrators

Temporal / Camunda / Inngest

Overkill for 80% of Jobs

Distributed multi-day saga engines

Cold Start:50ms - 200ms per step
Memory:Heavy multi-cluster footprint
Causality & Order:Full event-sourced deterministic replay
Durability:Unrivaled multi-week saga durability
Deploy Time:Tied to rolling worker container updates
Complexity:Massive cluster tax (Temporal server, Cassandra/DB)

SpectraFlux Appliance

SpectraFlux Wasmtime Chassis

Sweet Spot

Event-driven micro-worker execution chassis

Cold Start:< 0.8ms (instance pooling)
Memory:< 25MB chassis (16MB pooling, up to 4GB per cell)
Causality & Order:Built-in HLC CausalGuards & watermarks
Durability:Built-in 80/20 durable steps (ctx.step)
Deploy Time:Instant hot-swap via API (200ms, 0 downtime)
Complexity:Zero cluster tax: single drop-in Docker binary

Frequently asked questions

Everything you need to know about SpectraFlux, 80/20 idempotency, fluxcell granularity, and architectural trade-offs.

Why would I choose SpectraFlux over traditional Node.js or Go worker pods?
Traditional container workers suffer from severe resource bloat and deployment friction. Running 50 separate background workers in Kubernetes consumes 5 to 15 GB of RAM, and deploying a single bug fix requires rebuilding a 500MB Docker image and rolling pods. SpectraFlux packs 50 isolated WebAssembly fluxcells into a single < 25MB chassis container (< 0.8ms cold starts) and allows hot-swapping precompiled .wasm modules in milliseconds via API without restarting the container.
How does SpectraFlux solve inconsistent state problems across microservices?
Microservices frequently desynchronize when message brokers deliver events out-of-order (due to network partitions or consumer rebalancing) or when partial retries repeat external side effects. SpectraFlux solves this with two core primitives: (1) Monotonic Hybrid Logical Clock (HLC) CausalGuards that automatically detect and discard stale out-of-order events, and (2) 80/20 Durable Steps (ctx.step) that memoize external side effects (e.g. Stripe, Twilio) in local KV storage so retries never duplicate operations.
How does the 80/20 durable step (ctx.step) compare to Temporal or Inngest?
Temporal is exceptional for complex, multi-week human-in-the-loop sagas, but requires a massive operational footprint (dedicated Temporal cluster, Cassandra/Postgres, separate worker daemons) and adds 50-200ms latency per step. 80% of backend worker tasks just need: 'Charge credit card, update database, publish notification, and never double-charge on retry.' SpectraFlux provides ctx.step in one line of code backed by local embedded Kevy storage with sub-millisecond execution and zero cluster tax.
When should I NOT use SpectraFlux?
We believe in choosing the right tool for the job. You should look elsewhere if: (1) You require multi-week, human-in-the-loop workflows with paused execution across days (use Temporal); (2) Your handlers rely on heavy native C-extension libraries like Pandas or proprietary OS drivers that cannot compile to WASI (use standard Python/Node containers); or (3) You are building a traditional synchronous REST monolith without a message broker or CQRS write-path.
Do I have to use SpectraGQL to use SpectraFlux?
No. While SpectraFlux was designed to pair seamlessly with SpectraGQL (consuming verified caller identity claims and monotonic HLC timestamps), SpectraFlux is fully broker-agnostic and functions standalone. It consumes directly from standard NATS JetStream, Apache Kafka, Redpanda, or Redis Streams, and exposes standard HTTP endpoints.
What is the 'Zero-Compiler Container' invariant?
SpectraFlux runtime containers NEVER bundle rustc, cargo, or git. Images remain ultra-lean (< 25 MB). Guest fluxcells are compiled in external CI/CD pipelines and deployed dynamically to the running chassis via the Deployer API (POST /_flux/deployer/upload) without restarting the container.
Why are internal storage and fluxcell storage strictly decoupled?
Storage inside SpectraFlux is partitioned into two isolated tiers: 'internal-storage' (reserved strictly for chassis operations like Saga checkpoints, magic-link OTP tokens, and domain traces via embedded Kevy) and 'fluxcell-storage' (dedicated exclusively to guest fluxcell application state and Redis protocol commands). Host ABI linker boundaries prevent guest code from corrupting chassis state.
Why does SpectraFlux require PostgreSQL for relational storage?
SpectraFlux standardizes exclusively on PostgreSQL ('Postgres or Bust') to eliminate dialect fragmentation and avoid container bloat. Database migrations are plain SQL files embedded directly into the binary at compile time (include_str!). Versions are tracked automatically in schema_migrations.
SpectraFlux deep-space geometric flux blueprint

High-velocity WebAssembly workers for your write path

Deploy the ultra-lean execution chassis that eliminates duplicate side-effects, runs 50 micro-workers in a single container, and provides 80/20 durability without cluster bloat.

Ultra-lean < 25 MB container.

OPEN SOURCE · MIT LICENSED · NO SAAS TIER