Accepted commands are stored in Postgres in the same transaction as the follow-up work. A worker or engine crash does not drop that progress.
How it works
The work is the log.The worker is replaceable.
One Postgres log. Workers can die. The workflow does not.
Activities hit real services
Charges, credits, accounts, and reports go over HTTP. Flip payments or credit from the live demo and watch the workflow react.
Recovery is bounded
A dead worker loses its lease. Another continues. Time to resume is lease length plus the poll interval.
Guarantees
What survives a crash.
Each activity result is recorded at most once. History never has two ActivityCompleted events for the same command.
A dead worker loses its lease. Another worker continues. Recovery is bounded by the lease time plus the poll interval.
A late completion from a worker that lost its lease is rejected.
Failed activities retry with backoff, up to the configured limit.
Timers still fire if the engine was down when they came due.
Workflow code that changes its commands is rejected as non-deterministic.
Limits
What this demo does not promise.
Activities run at least once. A crash after the side effect and before the result is recorded runs the activity again. Duplicate side effects stay gone only when the activity sends the same idempotency key.
One Postgres database and one engine process. This is not a highly available cluster.
Not production grade. The demo uses a shared key, one tenant, and no workflow versioning.