Solid Queue（Rails）
Redisなし DBだけで — Rails 8デフォルトバックグラウンドジョブシステム
GitHub: rails/solid_queue
Solid Queueは37signalsが作ったDB基盤のActiveJobバックエンドで、Rails 8からデフォルト含まれます。「本当にRedisが必要か？」という問いから始まったプロジェクトです。
詳細なアーキテクチャ分析については韓国語版を参照してください。statusカラムの代わりに別テーブルで状態を管理するコアアイデア、10テーブルのDBスキーマ、ジョブライフサイクル（enqueue → dispatch → claim & execute）、3つのプロセスタイプ（Worker/Dispatcher/Scheduler）、非ブロッキングポーリングのためのFOR UPDATE SKIP LOCKED、enqueue_after_transaction_commit?によるトランザクション安全性が含まれます。
構造ダイアグラム
ジョブ状態別テーブル分離 (ERD)
各テーブルに最適化されたインデックス = 高速ポーリング
ジョブライフサイクル
3つのプロセスタイプ
キーポイント
GitHubでrails/solid_queueリポジトリを開く
db/migrate/ → 10テーブルスキーマを確認（状態別テーブル分離パターン）
lib/solid_queue/worker.rb → ポーリングループとclaimロジックを分析
lib/solid_queue/dispatcher.rb → 予約ジョブディスパッチロジックを分析
app/models/solid_queue/job.rb → enqueueフローを確認
app/models/solid_queue/ready_execution.rb → FOR UPDATE SKIP LOCKEDを確認
app/models/solid_queue/claimed_execution.rb → 実行/成功/失敗処理
lib/solid_queue/supervisor.rb → Fork vs Asyncプロセス管理
メリット
- ✓ Redis不要 — DBだけで完全なジョブシステム
- ✓ Rails 8デフォルト — 別途インストール不要ですぐ使用可能
- ✓ ActiveJob互換 — 既存ジョブコード変更なしで切替可能
- ✓ FOR UPDATE SKIP LOCKED — ワーカー間の非ブロッキング競合
- ✓ 同時性制御内蔵 — セマフォ基盤concurrency limit
- ✓ Pumaプラグイン — 開発時に別プロセス不要
デメリット
- ✗ Redis基盤Sidekiqよりスループットが低い場合がある
- ✗ DB負荷増加 — ジョブが多いとDBに書き込み負担
- ✗ SQLiteでSKIP LOCKED未サポート（graceful fallback）
- ✗ 大規模サービスでは依然としてSidekiq/Redisが有利
- ✗ Web UIがSidekiqより成熟度が低い（Mission Control別途）