void-background-job-pattern

Use a managed queue like Inngest, Trigger.dev, or Cloudflare Queues for event-driven work, and route handlers plus Vercel Cron for scheduled work. Emit an event from a Server Action and let the queue handle retries and execution outside the request lifecycle.

All three handle event-driven jobs with native retries and dead-letter queues. Inngest offers step.run checkpoints and event-ID dedupe, Trigger.dev has similar task primitives, and Cloudflare Queues fits Workers-based stacks. Pick based on your platform, not the work itself.

Avoid background jobs when the user is actively waiting for the result, when work completes in under 100ms, when it needs per-request context like cookies, or for one-off scripts. Inline execution or a runbook is cheaper and simpler in those cases.

Inngest and Trigger.dev dedupe on the event ID automatically. Otherwise use an inbox table with INSERT ON CONFLICT DO NOTHING keyed on the event ID, or design the service operation to be safely re-runnable, such as UPDATE WHERE status equals pending.

Cron routes need a concurrency lock, such as Redis SETNX or a Postgres advisory lock, to prevent overlapping runs. They also need the CRON_SECRET authorization check and explicit error reporting to Sentry, since a silent 500 means failures go unnoticed.