Durability & Restate

Durability is the reason palumb exists as more than a “send” API. palumb runs your workflows on its engine, built on Restate, a durable execution engine — and that gives you guarantees you would otherwise build by hand.

What “durable” means here

As palumb drives your workflow, it records each completed step. If a process crashes, is redeployed, or palumb restarts, the run resumes from where it left off instead of starting over:

• Completed steps are not re-run. A step.send that already succeeded is not repeated after a crash.
• Timers survive. A step.delay (“wait 60 seconds, then send”) or a digest window keeps waiting across restarts — a durable timer, not an in-memory setTimeout.
• Retries are automatic. A transient failure in a durable step is retried by the engine until it succeeds or is declared terminal.

You write straight-line code; the engine makes it crash-proof.

Durable steps

Every step.* call is a durable step: palumb journals its result and never repeats it on replay. Your workflow body is re-run from the top on each step, with completed steps hydrated from the journal — so anything with a side effect (an HTTP call, a non-deterministic value) belongs inside a step (step.run), not in the bare body. step.send is already a durable, idempotent step.

Keyed, serialized state

palumb’s digest building block is keyed durable state: addressed by a key (typically the subscriber) with serialized access per key. Every subscriber gets an independent batch, and concurrent updates to the same subscriber’s batch never race — you get this without running a database or a lock, and palumb hosts it.

What you do not operate

palumb runs the durable engine as part of the managed platform. You write plain TypeScript behind one signed webhook and connect it once (PUT /v1/bridge); you do not provision, scale, or back up the runtime. The durability is part of the product.

Next

• Architecture — where the engine sits in the system.
• Digest — keyed durable state you can use today.