backend // stack
Background work with retries, so spikes never become outages.
Webhooks, CRM syncs, and emails move to Sidekiq workers backed by Redis, with retries and dead-letter queues. Request cycles stay fast while slow dependencies fail and recover out of band.
Use for webhooks, syncs, and emails; never fire third-party calls inline in requests.
why we use it
(01) Requests stay fast
Mutations enqueue a job and return in milliseconds. The user never waits on a CRM API or an SMTP handshake.
(02) Failures recover alone
Exponential backoff with dead-letter queues means a vendor outage becomes a delayed sync, not lost data.
(03) Spikes flatten out
Concurrency limits and scheduled jobs absorb campaign traffic that would exhaust inline request threads.
scope
(01) Sidekiq queues with retry and dead-letter configuration
(02) Idempotent jobs safe to replay after vendor outages
(03) Scheduled and batched syncs for CRM and email providers
(04) Queue latency and failure monitoring wired to alerts
tradeoffs
Our default versus the common alternative, stated honestly.
| dimension | 2sh | traditional |
|---|---|---|
| Responsiveness | Requests return in milliseconds, work completes async | Users wait on third-party APIs per click |
| Durability | Failed jobs retry with visibility into the dead-letter queue | Silent failures with no retry story |
| Load shape | Workers absorb spikes with bounded concurrency | Thread pools exhausted by slow inline calls |
| When not queues | Reads and validations stay synchronous where immediacy matters | Queueing everything, including what the user is waiting for |
Not sure Redis + Sidekiq fits your estate?
In the audit we map your estate, model the cost of staying versus moving, and document the recommendation in writing.