solid-queue-and-sidekiq

What problem does it solve?

AI coding agents consistently make critical, costly mistakes when implementing Ruby on Rails background jobs: they select the wrong backend (Solid Queue vs Sidekiq) for the project's needs, skip idempotency design leading to duplicate charges or side effects on retry, enqueue jobs before database transactions commit causing ActiveRecord::RecordNotFound errors, and overuse async processing for trivial work that adds unnecessary overhead and latency.

Core Features & Use Cases

• Backend selection decision matrix: Clear, opinionated guidance to choose between Solid Queue (Rails 8 default, no Redis required) and Sidekiq (for existing Redis infrastructure or advanced Pro/Enterprise features like rate limiting and batch processing).
• Idempotent job design patterns: Proven strategies to build jobs that safely retry without duplicate side effects, including state checks, external idempotency keys, and database unique constraints.
• Production-grade best practices: End-to-end guidance on retry/backoff configuration, scheduled job setup, queue separation, concurrency controls, dead job handling, and testing patterns for ActiveJob, Sidekiq, and Solid Queue aligned with senior Rails developer conventions.
• Use case example: A Rails 8 SaaS developer can use this skill to correctly set up Solid Queue for recurring daily digest emails, ensure payment processing jobs never double-charge customers on network retries, and separate latency-sensitive mailer queues from heavy report queues to prevent processing bottlenecks.

Quick Start

Use the solid-queue-and-sidekiq skill to design an idempotent payment processing job that retries safely on Stripe API failures and enqueues only after the order transaction commits.