Belajar Ruby on Rails - Background Jobs Scale & Solid Stack

#Pendahuluan

Setelah di episode 11 kalian mengenal Active Job dan di episode 12 caching, episode 22 menyatukan keduanya dalam satu arsitektur: Solid Stack. Rails 8 memperkenalkan pendekatan baru yang radikal: menggantikan tiga layanan infrastruktur klasik — Redis untuk queue, cache, dan pub/sub — dengan database yang sudah kalian miliki.

Mengapa episode ini penting? Karena setiap layanan tambahan (Redis) berarti satu lagi hal yang harus diinstall, dimonitor, di-backup, dan di-scaling. Solid Stack menyederhanakan operasional secara drastis: satu PostgreSQL untuk segalanya. Memahami kapan Solid Stack cukup — dan kapan harus Redis — adalah keputusan arsitektur penting di 2026.

#Apa Itu Solid Stack

Solid Stack terdiri dari tiga komponen database-driven:

Ketiganya memakai PostgreSQL (atau MySQL) sebagai tempat penyimpanan — tabel yang dikelola migration Rails sendiri. Hasilnya: deployment yang lebih sedikit bergerak, lebih mudah di-backup (satu database), dan satu source of truth untuk transaksionalitas.

#Solid Queue: Queue di Database

Solid Queue menyimpan job sebagai baris tabel:

bundle add solid_queue
bin/rails solid_queue:install
bin/rails db:migrate

Membuat tabel solid_queue_jobs, solid_queue_scheduled_executions, dan lainnya. Aktifkan sebagai adapter:

config/environments/production.rb

config.active_job.queue_adapter = :solid_queue

Menjalankan worker:

bin/rails solid_queue:start

Keunggulan khas Solid Queue — transactional enqueue:

Enqueue transactional

ActiveRecord::Base.transaction do
  post.save!
  NotificationJob.perform_later(post.id)
end

Job di-enqueue dalam transaksi yang sama dengan perubahan data. Jika transaksi di-rollback, job ikut batal — tidak ada "job mengirim notifikasi untuk data yang tidak jadi disimpan". Sidekiq+Redis tidak bisa melakukan ini tanpa memisahkan kedua operasi.

#Solid Cache: Cache di Database

Solid Cache menggunakan database sebagai store cache:

config/environments/production.rb

config.cache_store = :solid_cache_store

Karena cache kini di database yang sama, integrasi dengan fragment cache (episode 12) menjadi transaksional dan mudah di-backup. Solid Cache menggunakan write-through + back-end polling yang membuatnya mengejar performa Redis untuk sebagian besar beban, sambil menghilangkan satu infra.

#Solid Cable: Pub/Sub di Database

Untuk Action Cable realtime (episode 14), Solid Cable menyimpan pesan pub/sub di database:

config/environments/production.rb

config.solid_cable.url = ...  # konfigurasi database cable

Solid Cable menggantikan Redis pub/sub untuk kebanyakan aplikasi realtime. Ia menulis pesan ke tabel dan memanfaatkan mekanisme notification PostgreSQL (LISTEN/NOTIFY atau polling) untuk mendistribusikan ke koneksi WebSocket.

#Kapan Redis Masih Diperlukan

Solid Stack sangat cocok untuk mayoritas aplikasi — tetapi Redis tetap unggul di beberapa skenario:

• Throughput sangat tinggi — ratusan ribu job per detik (Solid Queue berbasis database memiliki overhead baris).
• Cache dengan latensi ekstrem — Redis sub-milidetik untuk hit cache terpanas.
• Fitur Redis khusus — sorted sets, pub/sub lintas aplikasi, rate limiter shared (episode 20), ephemeral store.
• Arsitektur multi-service — beberapa aplikasi berbagi satu Redis.

Pendekatan pragmatis di 2026: mulai dengan Solid Stack, ukur, dan pindahkan komponen tertentu ke Redis hanya jika data menunjukkan kebutuhan nyata. Prinsip omakase Rails 8 mengadopsi default database-driven karena sesuai untuk mayoritas kasus.

#Scaling Worker

Solid Queue menyediakan cara scaling worker yang fleksibel:

config/queue.yml

production:
  dispatch:
    batch_size: 100
  polling_interval: 0.1
  queues:
    - [default, 3]
    - [mailers, 2]
    - [low_priority, 1]
  workers:
    - queues: [default, mailers]
      threads: 3
    - queues: [low_priority]
      threads: 1

Prioritas queue dinyatakan sebagai bobot: [default, 3] artinya default diproses 3x lebih sering daripada [low_priority, 1]. Untuk beban tinggi, jalankan beberapa worker process (horizontal) di mesin berbeda — semua berbagi tabel queue yang sama.

#Produksi dengan Solid Stack

Checklist produksi database-driven:

1. Satu database, beberapa connection pools — pastikan pool: cukup untuk app + worker + cable.
2. Jalankan worker sebagai proses terpisah — bin/rails solid_queue:start (episode 24 untuk process manager).
3. Monitor tabel queue — dashboard Solid Queue (jalur /solid_queue) menunjukkan job pending/berjalan.
4. Backup satu database — semuanya (app data, queue, cache, cable) tercakup; pastikan retention job sesuai kebutuhan.
5. Job terjadwal — Solid Queue punya scheduler internal (solid_queue:schedules); tidak butuh cron eksternal.

bin/rails runner 'p SolidQueue::Job.group(:status).count'

#Common Pitfalls

• Database jadi bottleneck — semua beban di satu DB; monitor IOPS dan siapkan peningkatan kapasitas.
• Worker tidak jalan — job antri selamanya; pastikan solid_queue:start selalu berjalan (systemd/Kamal).
• Queue tak terprioritas — job penting antri di belakang batch besar; atur bobot di queue.yml.
• Cache membesar tanpa batas — set expires_in dan ukur; database cache harus di-prune.
• Migrasi Solid Queue tidak dijalankan — job error; pastikan solid_queue:install + migrate di tiap environment.
• Berpindah ke Redis tanpa pengukuran — kompleksitas naik tanpa bukti kebutuhan; ukur dulu.

#Penutup

Episode 22 membekali kalian Solid Stack Rails 8: Solid Queue, Solid Cache, dan Solid Cable sebagai komponen database-driven yang menghapus Redis dari mayoritas deployment, keunggulan transactional enqueue, kapan Redis masih diperlukan, strategi scaling worker, dan checklist produksi database-driven.

Inti yang harus dibawa pulang:

• Solid Stack = queue + cache + cable dalam satu database PostgreSQL.
• Solid Queue: transactional enqueue, worker via bin/rails solid_queue:start.
• Solid Cache: cache store database-driven; Solid Cable: pub/sub database-driven.
• Redis tetap unggul untuk throughput sangat tinggi & fitur khusus.
• Mulai dengan Solid Stack, ukur, pindah ke Redis hanya jika data mendukung.

Di episode 23 selanjutnya kita akan membedah deployment: Kamal & Docker — deploy Rails ke VPS dengan Kamal, Dockerfile produksi, dan perbandingan managed hosting. Sampai jumpa di episode 23!