Our Sidekiq queue was growing. Adding more workers wasn't solving the problem.

In a Rails application, background jobs help move expensive work away from customer-facing requests.

Emails.
File processing.
API integrations.
Reports.
Data imports.

But as job volume grows, teams often take the obvious approach:

Increase Sidekiq concurrency.

More workers should mean more jobs processed, right?

Not always.

We need to look at what those workers are actually doing.

If jobs are waiting for external APIs, increasing concurrency may create more API pressure.

If jobs are database-heavy, they can exhaust ActiveRecord connections.

If jobs consume too much memory, adding workers can increase server costs without improving throughput.

The better approach is to understand the workload first:

- Separate queues based on priority and workload.
- Measure queue latency and job execution time.
- Match Sidekiq concurrency with database connection capacity.
- Use retries carefully to avoid retry storms.
- Track failed jobs and recurring failures.
- Scale workers based on actual queue demand.

Also, not every workload needs Sidekiq.

For simpler or infrastructure-managed workloads, a cloud queue such as AWS SQS may be worth considering.

Important learning:
Background job scaling isn't about running more workers.

It's about processing more work with predictable latency, controlled resource usage and reasonable infrastructure costs.

Measure throughput before increasing concurrency.

Otherwise, you may end up paying more to create a bigger bottleneck.