When to use Queue

Decide when Queue is the right primitive compared with Workflow, Cron, or inline request handling.

Use Queue when you want to hand work off and let another system process it later. The main request should return quickly, while retries, delays, and provider-managed execution happen in the background.

Choose Queue when

Queue is usually the right tool when:

  • one request should enqueue work and return quickly
  • the job is independent from the current response
  • retries or delayed delivery matter
  • you want to move between local and hosted providers without changing call sites

Examples:

  • send a welcome email
  • fan out webhook processing
  • enqueue image or document processing
  • buffer events before a slower downstream system

Queue vs Workflow

Choose Queue when you need simple background execution for one job at a time.

Choose Workflow when you need:

  • multi-step orchestration
  • long-running state across steps
  • branching and resumable execution
  • durable progress tracking for a whole process, not one message

If the job can be described as "enqueue this work item and let a handler process it," Queue is the simpler fit. If the job sounds like "run this process across several coordinated stages," Workflow is the better primitive.

Queue vs Cron

Choose Queue when work starts because your application asked for it.

Choose Cron when work starts because time passed.

Use Queue for:

  • user-triggered jobs
  • event-triggered background work
  • one-off delayed sends

Use Cron for:

  • hourly or daily maintenance
  • recurring sync jobs
  • scheduled cleanup or reporting

Cron can enqueue Queue jobs, but it should not replace them. Cron decides when work starts. Queue decides how one unit of work is delivered and processed.

When Queue is not the right primitive

Queue is usually the wrong choice when:

  • the caller needs the result before responding
  • the work is so small that inline execution is simpler
  • you need a recurring schedule instead of event-triggered delivery
  • you need a durable multi-step process instead of one job handler
  • provider-native callback or orchestration semantics dominate the design