ZFlow
Durable execution, event streaming, and code runtime.
ZFlow is the system of action. Every side-effect in a DOSS application — a write to an external API, a scheduled task, a user-triggered automation — runs as a durable workflow with checkpointed state. Built on Restate under the hood, it gives every ZSL program the same retry, replay, and observability story out of the box.
What durable execution buys you
Crash-safe side effects
A workflow can outlive the process running it. State is checkpointed after every step; on restart the runtime picks up exactly where it left off.
At-least-once with idempotency hints
Calls to external APIs are journaled. The runtime surfaces idempotency keys so retries don't double-charge a vendor or double-send an email.
Replayable history
Every execution is a record of its own inputs, outputs, and decisions. Step through a week-old run to see exactly what the workflow saw.
No workflow-as-YAML
Workflows are TypeScript code authored in ZSL. The durability is a runtime property, not a config surface.
Trigger surface
| Trigger | Source | Delivery | Typical use |
|---|---|---|---|
| Data change | ZebraDB CDC → Kafka | At-least-once, keyed by row | Sync, recalc, index update |
| Schedule | Cron expression | At-least-once, wall-clock fires | Nightly rollups, reminders |
| Webhook | Tenant-scoped URL | Exactly-once via dedup key | Vendor callbacks, EDI drops |
| User action | App UI or agent call | Exactly-once via request ID | Approvals, kick-off jobs |
| Flow output | Another ZFlow run | Typed channel | Fan-out, sagas |
Stack
In the stack
Every ZSL workflow compiles to a ZFlow durable function.
CDC from Z-Tables drives ZFlow triggers; workflows write back via the Postgres wire.
Agent tool calls run as durable ZFlow executions so dossbot can retry without side-effect duplication.
ZFlow executions emit OCEL events into the context graph.
