Workflow Engine
Trigger.dev for background jobs, retries, idempotency, and a dashboard. Work that runs when you're not looking.
What this system covers
Background jobs
Work that runs asynchronously: sending emails, syncing data, generating reports. Jobs are queued, processed by workers, and retried on failure with configurable backoff.
Retries & dead-letter
Failed jobs are retried with exponential backoff. After max attempts, they move to a dead-letter state so you can inspect and replay. No silent drops.
Orchestration
Multi-step workflows (e.g. onboarding sequence, subscription lifecycle) are modeled as workflows with steps and dependencies. We support sequential and parallel execution where needed.
Decisions & trade-offs
We use Trigger.dev so you get a durable job queue, retries, idempotency, and a dashboard without running your own workers initially. For an MVP and early growth, we prefer a managed queue over self-hosted (e.g. BullMQ) or Cloudflare Queues so you can focus on product; we document idempotency and failure handling so critical jobs (billing, notifications) stay safe.
Pros
- Managed queue: no infra to run; dashboard for status and failed jobs.
- Retries and idempotency are first-class; we enforce them for billing-related jobs.
- Job payloads are versioned so you can evolve schemas without breaking in-flight work.
- Scales with your app; you can move to Cloudflare Queue or self-hosted later if needed.
Trade-offs
- Trigger.dev is a third-party dependency; we accept that for speed and ops simplicity.
- Very high throughput or strict data residency may require a self-hosted or CF Queue path.
- Orchestration (multi-step workflows) is basic; complex DAGs may need custom logic.