The Service schedules Tasks and persists Event History. Workers poll Task Queues for Workflow and Activity Tasks. Put external API and database operations in Activities; durable coordination has storage and scheduling costs and requires Workers.
Use these roles to design recoverable order processing and calls across services.
Retries and idempotency
This example uses one order key, at most three attempts, and retry waits of one then two seconds.
↔ Drag to explore
Principles and uses
Compare retryable failure with a lost response, and see an idempotency key prevent duplicate effects.
An Activity may execute again. Design deduplication with the external system.
This example permits three attempts with a one-second initial interval and a backoff coefficient of two. After a retryable error, a later request succeeds but its response is lost. The API returns its stored result for the same key. Retry behavior depends on errors, timeouts, and policy.
Use idempotency for payments, mail, or external writes when success may precede result reporting. Retries alone do not guarantee exactly-once effects.
Event History and Replay
The example payment Activity has a persisted completion. Its external effect has already occurred once.
↔ Drag to explore
Principles and uses
Recover Worker state from recorded results and continue with new work after a crash.
Replay runs Workflow code against Event History. It reuses results of recorded completed Activities.
A payment result is persisted before the Worker crashes. A new Worker emits compatible Commands, recovers that result, then proceeds to shipment. Workflow code must be deterministic and changes must remain compatible; longer History can increase replay work.
Use replay to recover long-running executions after Worker replacement and to assess code compatibility. External work without a recorded completion still needs retry and idempotency design.
Timers and Signals
The example waits for a five-minute Timer and then external approval: two different kinds of waiting.
↔ Drag to explore
Principles and uses
See a durable Timer and an external Signal make a waiting Workflow runnable again.
Timers and Signals turn waits into History events without occupying a Worker thread for each waiting Workflow.
The example waits for a five-minute Timer, then approval. While the Service is available, it can record timer expiration and Signals without a running Worker. Available Workers process subsequent Workflow Tasks. Resumption depends on Service and Worker availability and scheduling.
Use durable waits for approvals and follow-ups. Timers do not promise sub-second scheduling precision or immediate resumption.