- Home
- Skills
- Kaakati
- Rails Enterprise Dev
- Sidekiq Async Patterns
sidekiq-async-patterns_skill
- Shell
6
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill kaakati/rails-enterprise-dev --skill sidekiq-async-patterns- SKILL.md25.4 KB
Overview
This skill is a practical, production-ready guide for implementing background job processing with Sidekiq in Ruby on Rails. It focuses on creating idempotent jobs, configuring queues and concurrency, handling retries and errors, and scheduling recurring work. Use it to standardize async patterns across any Rails project.
How this skill works
The skill inspects job definitions, Sidekiq configuration, queue assignments, scheduled/recurring YAML, and Sidekiq initializers to validate patterns and recommend changes. It enforces core principles: pass IDs not objects, fail fast on missing records, keep payloads small, and make jobs idempotent. It also maps queue priorities to workload types and recommends retry and error-handling strategies.
When to use it
- When adding new background jobs or migrating from another queue system
- When designing queue priorities and Sidekiq concurrency settings
- When implementing retry, backoff, and death handlers
- When making jobs idempotent and safe to re-run
- When scheduling recurring or cron-based jobs
- When optimizing job performance and monitoring Sidekiq health
Best practices
- Always pass primitive IDs/attributes; avoid serializing AR objects
- Design jobs to be idempotent and check state before performing side effects
- Use queue priorities: critical, default, notifications, integrations, bulk, scheduled, low
- Retry only recoverable errors; discard on unrecoverable/deserialization exceptions
- Keep jobs small and batch large work into many short jobs
- Protect Sidekiq Web UI and integrate death handlers with monitoring (Sentry, logs)
Example use cases
- PaymentProcessingJob on :critical queue for time-sensitive payments with strict retries
- SendNewsletterJob on :low queue for bulk email batches to avoid contention
- SyncExternalDataJob on :integrations with retry/backoff for flaky APIs
- ImportJob that processes CSV rows in batches and reports progress to a DB record
- DailyCleanup and HourlySync configured in recurring.yml for scheduled maintenance
FAQ
Check and persist a marker before performing side effects (for example, return if a sent_at timestamp exists), and always operate on record IDs rather than serialized objects.
When should I use sidekiq-unique-jobs?
Use it when you must prevent concurrent or duplicate work for the same resource (e.g., locking on resource_id) to avoid race conditions and wasted API calls.