Long-running workflows, retries, timeouts, and schedules

Overview

• Long-running workflows persist progress while waiting for jobs, timers, or people.
• Retries repeat transiently failing work; timeouts cap waits; schedules start work at defined times.
• Durable waiting should not consume an open request or a sleeping application worker.

Why this matters

Claims, document processing, and review can outlive any one process.

An everyday example

A case file remains open while waiting for an invoice, with a reminder date written on it.

A technical example

Start intake, wait up to a business-defined period for review, then escalate or expire; schedule periodic index refreshes.

How it works

1. Persist state
2. Register durable timer/event wait
3. Release worker
4. Receive event/timer
5. Resume
6. Retry eligible activities within deadline.

Architecture and flow

Start → durable steps → persisted wait → event/timer → resume → finish.

The insurance assistant example

Remind the customer about missing documents without losing progress if the server deploys overnight.

When to use it

Multi-day tasks, approvals, scheduled ingestion, and recoverable background work.

When to avoid it

Do not use setTimeout in one Node process as the only record of a critical reminder.

Interview answer

“I persist progress and use durable timers or correlated events. Retries and timeouts have bounded policies and observable outcomes.”

Benefits, trade-offs, and production considerations

• Define schedule timezone and daylight-saving behavior where applicable.
• Avoid overlapping refresh jobs, stale review events, and nested retries that multiply provider cost.