1️⃣ Жодних блокувань усієї таблиці
Коли воркер бере задачу з бази, він може заблокувати конкретний рядок. Інші воркери пропускають заблоковані рядки (SKIP LOCKED) і переходять до наступних задач, не чекаючи на звільнення зайнятих.
2️⃣ Менше витрат на інфраструктуру
Вам більше не обов’язково конфігурувати, моніторити та оплачувати окремий Redis-кластер для staging і production. Менше компонентів — простіше розгортання та підтримка.
3️⃣ Транзакційна цілісність (Transactional Jobs)
Можна налаштувати постановку задач у чергу в межах тієї самої транзакції, що й запис бізнес-даних. Якщо транзакція відкотиться (rollback), задача не буде зафіксована в черзі.
Це допомагає уникнути класичної проблеми з Sidekiq/Redis, коли фоновий воркер намагається обробити задачу раніше, ніж транзакція з основними даними буде закомічена.
4️⃣ Підтримка складних сценаріїв із коробки
Solid Queue підтримує:
• Delayed jobs — відкладені задачі.
• Concurrency controls — обмеження паралельного виконання.
• Pausing queues — призупинення черг.
• Recurring jobs — періодичні задачі за розкладом.
🛠 Як спробувати у своєму Rails-проєкті
Gemfile:
gem "solid_queue"
Конфігурація в
config/environments/production.rb:
config.active_job.queue_adapter = :solid_queue
Далі встановлюємо конфігурацію та міграції Solid Queue:
bin/rails solid_queue:install
Запускаємо воркери:
bin/jobs
🔥 Підсумок для співбесіди
Solid Queue — це не просто альтернатива Sidekiq. Це крок до простішої архітектури Rails-застосунків, меншої кількості зовнішніх залежностей і нижчої вартості підтримки інфраструктури.
Водночас Sidekiq залишається чудовим вибором для проєктів із високим навантаженням, а продуктивність Solid Queue залежить від конкретної БД, навантаження та конфігурації.
А ви вже перейшли на Solid Queue у Rails 8 чи поки залишаєтесь на перевіреній зв’язці Sidekiq + Redis?
👇 Пишіть у коментарях!
TikTok | Instagram | Telegram