Alasan Meninggalkan Redis dan Beralih ke SolidQueue

• Rails 8 menghapus ketergantungan pada Redis dari stack default dan beralih agar semua pekerjaan diproses di atas database relasional (RDB) melalui SolidQueue·SolidCache·SolidCable
• Redis cepat dan stabil, tetapi menimbulkan kompleksitas operasional seperti konfigurasi, keamanan, manajemen klaster, dan backup
• SolidQueue memanfaatkan fitur PostgreSQL FOR UPDATE SKIP LOCKED untuk mewujudkan pemrosesan pekerjaan paralel tanpa contention
• Fitur berbayar Redis+Sidekiq seperti pekerjaan periodik, kontrol konkurensi, dan dashboard pemantauan (Mission Control) disediakan secara gratis
• Untuk sebagian besar aplikasi Rails, SolidQueue sudah memadai; hanya beberapa kasus yang membutuhkan pemrosesan ultra-cepat dan real-time yang tetap memerlukan Redis

---

Biaya Tersembunyi Redis

• Di luar biaya hosting yang sederhana, Redis juga membawa beban pengelolaan berkelanjutan seperti instalasi, pemeliharaan, konfigurasi keamanan, dan manajemen klaster HA
  • Diperlukan koneksi jaringan dan pengaturan firewall antara Rails dan Redis, autentikasi klien, serta orkestrasi proses Sidekiq
• Saat terjadi gangguan, Redis dan RDBMS harus di-debug secara bersamaan, dan juga dibutuhkan strategi backup ganda
• Sebaliknya, pada stack Rails tanpa Redis, penyederhanaan dimungkinkan karena cukup mengelola PostgreSQL saja

Cara Kerja SolidQueue

• Menggunakan fitur PostgreSQL FOR UPDATE SKIP LOCKED agar banyak worker dapat mengambil pekerjaan secara bersamaan tanpa lock contention
• Struktur tabel utama
  1. solid_queue_jobs: menyimpan metadata pekerjaan
  2. solid_queue_scheduled_executions: menunggu pekerjaan terjadwal
  3. solid_queue_ready_executions: antrean pekerjaan yang siap dieksekusi
• Proses worker, dispatcher, scheduler, dan supervisor melakukan polling berkala pada tabel yang berbeda dan saling bekerja sama
• Berkat desain MVCC dan autovacuum PostgreSQL, operasi insert dan delete dalam jumlah besar pun dapat ditangani secara stabil

Penjadwalan Pekerjaan Berulang

• SolidQueue menyediakan pekerjaan berulang bergaya cron secara bawaan, dengan konfigurasi melalui file config/recurring.yml
• Scheduler memasukkan pekerjaan yang sudah jatuh tempo ke antrean, lalu secara otomatis menjadwalkan waktu eksekusi berikutnya
• Menggunakan library Fugit untuk mem-parsing jadwal bahasa alami, dan Concurrent::ScheduledTask untuk membuat thread
• Mengadopsi pendekatan penjadwalan deterministik dari GoodJob agar jadwal tetap terjaga meski proses di-restart

Fitur Kontrol Konkurensi

• SolidQueue mendukung pembatasan eksekusi paralel per unit pekerjaan dengan pola semafor POSIX
  • Contoh: jika diatur limits_concurrency to: 1, key: ->(user) { user.id }, maka hanya 1 pekerjaan per pengguna yang akan dijalankan
• Dengan menetapkan masa berlaku semafor (duration), benturan pekerjaan dan deadlock dapat dicegah
• Tabel terkait
  • solid_queue_semaphores: melacak batas konkurensi
  • solid_queue_blocked_executions: menyimpan pekerjaan yang sedang menunggu

Pemantauan dengan Mission Control

• Mission Control Jobs adalah dashboard open source gratis untuk Rails 8 yang dapat dengan mudah di-mount pada path /jobs
• Fitur utama
  • Status antrean real-time, pelacakan pekerjaan gagal, kontrol retry/discard
  • Visualisasi timeline untuk pekerjaan terjadwal dan berulang
  • Grafik throughput dan metrik per antrean
• Mendukung kueri berbasis SQL sehingga analisis langsung dari database dimungkinkan tanpa alat tambahan

Migrasi dari Sidekiq ke SolidQueue

• Langkah 1: atur config.active_job.queue_adapter = :solid_queue
• Langkah 2: jalankan bundle add solid_queue, lalu rails solid_queue:install dan db:migrate
• Langkah 3: ubah jadwal cron di sidekiq.yml menjadi recurring.yml
• Langkah 4: tambahkan jobs: bundle exec rake solid_queue:start ke Procfile
• Langkah 5: hapus gem terkait Redis dan Sidekiq
• Kode ActiveJob yang ada tetap berjalan tanpa perlu modifikasi

Kapan Redis Masih Dibutuhkan

• Pemrosesan pekerjaan berkelanjutan lebih dari ribuan per detik
• Sistem real-time yang mewajibkan latensi di bawah 1 ms
• Kebutuhan akan struktur pub/sub yang kompleks atau rate limiting dan operasi counter yang canggih
• Sebagai contoh, Shopify menangani 833 request per detik dan mengoperasikan 1.172 proses worker dengan infrastruktur Redis

Panduan Implementasi Nyata

• Saat membuat aplikasi baru Rails 8, SolidQueue·SolidCache·SolidCable dikonfigurasi secara otomatis
• Disarankan menyiapkan koneksi database queue terpisah di config/database.yml
• Tambahkan autentikasi Mission Control dan mount route /jobs
• Tambahkan jobs: bundle exec rake solid_queue:start ke Procfile.dev, lalu jalankan seluruh stack dengan bin/dev
• Setelah membuat pekerjaan uji, statusnya dapat diperiksa melalui Mission Control

Masalah Umum dan Solusinya

• Konfigurasi database tunggal juga memungkinkan, tetapi fleksibilitas operasional berkurang
• Untuk Mission Control di lingkungan production, autentikasi wajib ditambahkan
• Interval polling default adalah 1 detik untuk pekerjaan terjadwal dan 0,2 detik untuk pekerjaan langsung, cocok untuk sebagian besar aplikasi
• Saat menggunakan ActionCable/Turbo Streams, SolidCable perlu diatur dengan koneksi DB terpisah

Skalabilitas dan Kinerja

• SolidQueue cukup skalabel untuk sebagian besar aplikasi Rails
• Berbasis PostgreSQL, SolidQueue dapat menangani 200–300 pekerjaan per detik, dan 37signals memproses 20 juta pekerjaan per hari tanpa Redis
• Tabel perbandingan

  Item	Redis + Sidekiq	SolidQueue
  Kompleksitas konfigurasi	Perlu layanan terpisah	Menggunakan DB bawaan
  Bahasa kueri	Perintah Redis	SQL
  Pemantauan	Dashboard terpisah	Mission Control
  Skenario gangguan	6 atau lebih	2
  Throughput	Ribuan/detik	200–300/detik
  Cocok untuk	99.9% aplikasi	95% aplikasi

Kesimpulan

• Redis dan Sidekiq adalah teknologi yang sangat baik, tetapi untuk sebagian besar aplikasi Rails keduanya menimbulkan kompleksitas dan biaya yang berlebihan
• SolidQueue mewujudkan penyederhanaan operasional, penghematan biaya, dan efisiensi pemeliharaan dengan pendekatan berbasis satu database
• Di era Rails 8, beralih ke SolidQueue direkomendasikan sebagai pilihan default

[kaydash]

Redis memang bagus.

[GN⁺]

Komentar Hacker News

• Saya pikir semua penulis open source berhak mengendalikan cakupan proyeknya
  Tetapi tim kami menyesal telah berpindah dari good_job ke SolidQueue
  Basecamp berfokus pada MySQL, jadi mereka tidak menerima query yang spesifik untuk engine RDBMS. Dari issue GitHub terlihat bahwa perhatian mereka hanya tertuju pada performa MySQL
  Selain itu, masih belum ada dukungan batch job (PR terkait)

  • Kedengarannya seperti kombinasi terburuk. Kami juga memakai MySQL, tetapi kami tidak bisa hidup tanpa query spesifik engine
    Dalam JOIN yang kompleks, MySQL sering menyusun query plan yang buruk, jadi saya memaksa urutannya dengan STRAIGHT_JOIN. Ini untuk antisipasi masa depan
  • Jika sudah sedalam itu terikat ke MySQL, bukankah logis memakai fitur khusus MySQL? Rasanya ada yang kurang masuk akal
  • Saya ingin mendengar alasan yang lebih spesifik mengapa GoodJob direkomendasikan dibanding SolidQueue
    Saya sedang membandingkan keduanya sebagai kandidat migrasi dari resque. GoodJob tidak kompatibel dengan mode transaction pgbouncer karena fitur khusus pg
    Perlu session persistence jadi agak merepotkan, tetapi peningkatan performanya tidak terlalu berarti di kebanyakan skala
    Meski begitu, model pengembangan dan keterbacaan kode GoodJob terasa jauh lebih meyakinkan
  • Setuju. good_job adalah pendekatan ideal untuk queue berbasis Postgres
  • Saya belum begitu paham SolidQueue, tetapi good_job benar-benar menyenangkan saat dipakai. Berjalan dengan sangat baik

• Jika lingkungan produksi bisa dibuat lebih sederhana, itu selalu hal yang bagus
  Menurut saya, situasi ideal di Rails adalah arsitektur yang bisa dengan mudah beralih ke Redis
  Akan bagus jika bisa mulai dengan SolidQueue lalu pindah ke Redis saat mentok pada batas skalabilitas
  Sebagian besar aplikasi Rails tidak punya trafik besar, jadi justru lebih rumit jika harus memelihara dua sistem

  • Rails menyediakan API abstrak bernama Active Job, jadi berpindah ke Redis cukup mudah
    Tentu ada aplikasi yang bergantung pada implementasi queue tertentu, tetapi dalam kasus umum cukup ubah konfigurasi
  • Saya penasaran apakah mode Redis AOF mencatat semua perubahan seperti WAL
    Saya juga ingin tahu apakah snapshot dipakai bersamaan agar log tidak membesar terus, dan apakah ini juga bekerja dalam mode terdistribusi
  • Jika terlalu bergantung pada transaksi, migrasi jadi sulit
    Terutama ketika pembuatan job terjadi bersamaan dengan perubahan DB lain, hilangnya jaminan itu menjadi masalah
  • Rails membingungkan karena prosesor background job tidak dipisahkan dari DB produksi
    Redis unggul di sini karena ringan dan menjadi penyimpanan state yang terpisah
    SolidQueue tampaknya tidak benar-benar memperjelas pemisahan ini (riverqueue.com)

• Saya sudah mencoba SolidQueue di side project saya
  Kesimpulannya, kalau Sidekiq tidak bermasalah, tidak ada alasan kuat untuk pindah
  Layak dipertimbangkan hanya jika ingin menghapus infrastruktur Redis
  Untuk proyek baru, GoodJob terasa lebih matang dan komunitasnya juga lebih baik
  UI SolidQueue terlalu sederhana sehingga tidak nyaman dipakai. Optimasi indeksnya juga kurang, jadi saat data menumpuk halamannya sempat macet
  Perlu juga mempertimbangkan bahwa memakai RDBMS menambah biaya pengelolaan connection pool

• Bagi yang khawatir soal skalabilitas, lihat benchmark Oban dari Elixir
  Di satu node saja, ia memproses satu juta job per menit. Sebagian besar aplikasi beban kerjanya jauh di bawah itu

  • Perusahaan kami juga memakai Oban, dan Oban menggunakan Redis sebagai notifier atau merekomendasikan polling (dokumen scaling)
  • Tetapi benchmark itu cukup jauh dari aplikasi nyata
    Strukturnya memasukkan 5000 job sekaligus dalam batch, jadi TPS nyatanya hanya sekitar 200
    Jika job dimasukkan satu per satu tanpa batch, beban transaksi SQL akan jauh lebih besar

• Bahkan sebelum SolidQueue, kami sudah menyimpan job di DB
  Keuntungannya adalah state produksi bisa di-snapshot apa adanya ke lingkungan pengembangan
  Tetapi rate limiter tetap kami taruh di Redis, agar beban DB tidak berlebihan

• Batasan queue berbasis DB adalah payload berukuran besar
  Jika JSON besar dimasukkan ke queue, itu jadi tidak efisien karena overhead penulisan ke DB
  Redis (Sidekiq) jauh lebih cepat untuk kasus seperti ini
  SolidQueue+SQLite masih oke jika hanya untuk meneruskan primary key
  Tetapi jika banyak worker melakukan polling ke DB yang sama, bottleneck akan cepat muncul

  • Dalam praktiknya, biasanya parameter job hanya mengirim satu atau dua ID. Lebih dari itu cenderung tidak efisien
  • Redis juga kurang cocok untuk payload besar karena batas memori
    Menurut saya, lebih baik simpan data besar di storage eksternal seperti S3 lalu hanya kirim referensinya
  • Toh bagian lain dari sistem juga tetap butuh storage, jadi memakai penyimpanan sementara seperti S3 atau garage terasa realistis
    Saya penasaran apakah ada materi yang merangkum hasil benchmark
  • Dokumentasi Sidekiq juga menyarankan agar hanya identifier yang dikirim
  • Menyimpan payload besar di Redis adalah praktik yang buruk karena memori itu terbatas

• SolidQueue menyebut SKIP LOCKED, tetapi mempertahankan transaksi untuk job yang berjalan 15 menit itu berisiko
  Transaksi yang terbuka lama merusak performa DB dan juga rentan saat jaringan terputus
  Struktur seperti ini bisa mengarah pada anti-pattern. Belakangan saya lihat tampaknya mereka memakai model lease

• Saya setuju dengan filosofi Postgres for everything
  Menyatukan semuanya secara sederhana ke PostgreSQL saja menurut saya adalah pilihan yang baik

  • Saya juga suka gagasan serba PG, tetapi saya sering mendengar, “kalau yang Anda punya hanya palu, semua terlihat seperti paku”
    Saya tidak tahu harus membantah analogi itu seperti apa
  • Sekarang storage NVMe sangat cepat sehingga saya merasa keunggulan Redis makin berkurang
    Apakah masih ada alasan memakai Redis jika itu hanya menambah kompleksitas?

• “Bisnis yang membutuhkan latensi di bawah 1 ms”, maksudnya menjalankan HFT dengan Rails?

  • Tentu tidak. Kalau melihat studi kasus SimpleThread, perusahaan itu jauh dari HFT
  • Mesin trading tentu tidak akan dijalankan dengan Rails, tetapi UI pemantauan trading bisa saja dibuat dengan Rails

• Postgres akan menelan dunia

  • Saya juga setuju. Suatu hari kalau ekstensi pg_kernel keluar, mungkin kita bisa menghapus Linux
  • Tetapi beberapa tahun lagi kita juga bisa sadar bahwa “Postgres for everything” adalah tren yang berlebihan, seperti “MongoDB for everything” dulu
  • Meski begitu, MySQL tetap mudah dirawat dan performanya juga cukup baik (saya bilang ini meskipun pengguna Postgres)
  • Sekarang saya memakai PGQM dan PG_CRON, dan itu jauh lebih rapi dibanding kombinasi MySQL + Redis + AWS yang dulu
  • Pada akhirnya yang penting adalah set fitur. RDBMS akan menelan dunia