Solid Queue and Sidekiq

Decide which job backend to run, design jobs that retry safely, and stop putting things in background jobs that don't belong there. AI agents over-async by reflex (Job.perform_later everywhere) and under-think idempotency (which is where retries bite).

Why this matters

Background jobs are infrastructure. Pick wrong and you're running Redis you didn't need, or your DB is melting under polling. Pick right and they're invisible until they fail — and when they fail, the question is always: "is it safe to retry?"

The opinion

Greenfield Rails 8: Solid Queue, no Redis. Existing Sidekiq investment or specific Sidekiq features needed (Pro/Enterprise rate limiting, batches): keep Sidekiq. Every job: idempotent by design. Retries with exponential backoff. External effects guarded by lookup-before-write. after_commit enqueue, never after_save.

Counter-positions:

• GoodJob — Postgres-only, mature, supports cron. Solid Queue covers ~all its features now and ships with Rails 8.
• delayed_job — fine for tiny apps, dated for everything else.
• Resque — historical, don't pick for new work.

Decision matrix — which backend