- Sidekiq OSS 7.3.10
- 36 jobs across 5 queues (critical, default, low, mailer, maintenance)
- sidekiq-unique-jobs (8.0.13) — 23 jobs use
lock: :until_executed - sidekiq-failures (1.1.0) — failure monitoring
- Production concurrency: 20 threads
- Custom middleware: error logging + Elasticsearch context tagging
| Feature | Impact |
|---|---|
| Reliable fetch (super_fetch) | Jobs survive Redis/process crashes without loss. Currently if our Sidekiq process dies mid-job, that job is gone. Critical for assign_lead_job, distribute_lead_job, and push_lead_job which handle real money. |
| Batches | Could simplify bulk distribution and Google Sheets export jobs — group child jobs, get a callback when all complete, track progress in the UI. |
| Queue pausing | Pause distribution during maintenance windows without stopping Sidekiq entirely. |
| Job expiration | Automatically expire stale jobs (e.g., time-sensitive lead notifications that are useless after N minutes). |
| Web UI search | Search for specific jobs by args — useful for debugging "what happened to lead #12345". |
| Statsd metrics | Pairs with our existing Elasticsearch logging for operational dashboards. |
| Priority support | Direct access to Sidekiq's author (Mike Perham). |
- $995/year is modest for the reliability gain alone
- Minimal migration effort — it's a drop-in replacement gem
Includes all Pro features plus the following.
| Feature | Current Workaround | Enterprise Replacement |
|---|---|---|
| Unique Jobs (built-in) | sidekiq-unique-jobs gem (8.0.13), used by 23 of 36 jobs |
Native implementation maintained by the same author. No third-party gem dependency. sidekiq-unique-jobs is a community gem with its own bugs/Redis scripts. |
| Periodic Jobs | Cron or scheduled Sidekiq jobs | Cron replacement that scales across processes with no single-point-of-failure cron machine. |
| Rate Limiting | No current solution | Throttle external API calls (GHL, Ringy, CRM integrations) to avoid rate limits. Very relevant for lead distribution channels. |
| Rolling Restarts | Capistrano stop/start with potential job loss | Zero-downtime deploys — critical for a lead distribution system where seconds matter. |
| Multi-Core (Sidekiqswarm) | Single Sidekiq process with 20 threads | Run multiple processes managed as one unit. Better utilization of server CPU cores. |
| Encryption | Not currently used | Encrypt job args in Redis — PII protection for lead data (names, phones, addresses sitting in Redis). |
| Historical Metrics | sidekiq-failures gem |
Built-in historical job metrics, potentially replacing sidekiq-failures. |
- Cost: ~3x more than Pro ($3,228/year vs $995/year). Price scales with thread count.
- Gem removal: Could drop
sidekiq-unique-jobsandsidekiq-failures, simplifying our dependency tree and middleware chain. - Migration work: Replacing
sidekiq-unique-jobslock declarations with Enterprise's native unique jobs syntax requires touching all 23 jobs. The lock semantics are similar but not identical — testing required. - Vendor lock-in: Harder to downgrade back to OSS if we build on Enterprise features (periodic jobs, rate limiting, encryption).
Pro is the clear value play — $995/year for reliable fetch alone is worth it when we're processing real lead assignments and payments. The batch and search features are nice bonuses.
Enterprise makes sense if any of these are pain points:
- We're hitting external API rate limits in lead distribution
sidekiq-unique-jobshas caused bugs or lock contention issues- We want zero-downtime Sidekiq deploys
- PII in Redis is a compliance concern
- We want to consolidate cron scheduling into Sidekiq
If none of those are urgent, start with Pro now and evaluate Enterprise later.