Redis छोड़कर SolidQueue पर जाने के कारण

• Rails 8 डिफ़ॉल्ट स्टैक से Redis dependency को हटाता है और SolidQueue·SolidCache·SolidCable के ज़रिए सभी कामों को relational database (RDB) पर प्रोसेस करने की ओर शिफ्ट करता है
• Redis तेज़ और भरोसेमंद है, लेकिन इससे configuration·security·cluster management·backup जैसी operational complexity बढ़ती है
• SolidQueue, PostgreSQL की FOR UPDATE SKIP LOCKED सुविधा का उपयोग करके lock contention के बिना parallel job processing लागू करता है
• recurring jobs, concurrency control, monitoring dashboard (Mission Control) जैसी Redis+Sidekiq की paid features को मुफ़्त में उपलब्ध कराता है
• ज़्यादातर Rails applications के लिए SolidQueue काफ़ी है; केवल ultra-fast·real-time processing वाले कुछ मामलों में ही Redis बनाए रखने की ज़रूरत है

---

Redis की छिपी हुई लागत

• Redis in सिर्फ़ hosting cost नहीं, बल्कि installation·maintenance·security configuration·HA cluster management जैसी लगातार operational overhead भी होती है
  • Rails और Redis के बीच network connection और firewall setup, client authentication, Sidekiq process orchestration की ज़रूरत होती है
• समस्या आने पर Redis और RDBMS दोनों systems को साथ में debug करना पड़ता है, और dual backup strategy भी चाहिए
• इसके उलट, Redis के बिना Rails stack में सिर्फ़ PostgreSQL एक ही manage करना होता है, जिससे चीज़ें सरल हो जाती हैं

SolidQueue कैसे काम करता है

• PostgreSQL की FOR UPDATE SKIP LOCKED सुविधा का इस्तेमाल करके कई workers lock contention के बिना एक साथ jobs उठा लेते हैं
• मुख्य table structure
  1. solid_queue_jobs: job metadata स्टोर करता है
  2. solid_queue_scheduled_executions: scheduled jobs की प्रतीक्षा
  3. solid_queue_ready_executions: execution के लिए तैयार job queue
• worker·dispatcher·scheduler·supervisor processes अलग-अलग tables को समय-समय पर poll करते हुए आपस में सहयोग करते हैं
• PostgreSQL के MVCC design और autovacuum की वजह से भारी मात्रा में insert·delete operations भी स्थिर रूप से संभाले जा सकते हैं

recurring job scheduling

• SolidQueue, cron style recurring jobs को डिफ़ॉल्ट रूप से सपोर्ट करता है, और इसे config/recurring.yml फ़ाइल में configure किया जाता है
• scheduler, execution time आने पर job को queue में डालता है और अगला execution time अपने-आप schedule कर देता है
• Fugit library natural language schedules को parse करती है, और Concurrent::ScheduledTask threads बनाता है
• GoodJob की deterministic scheduling पद्धति अपनाने से process restart के बाद भी schedule बना रहता है

concurrency control फीचर

• SolidQueue, POSIX semaphore pattern का उपयोग करके job unit के हिसाब से concurrent execution limit सपोर्ट करता है
  • उदाहरण: limits_concurrency to: 1, key: ->(user) { user.id } सेट करने पर हर user के लिए एक समय में सिर्फ़ 1 job चलेगी
• semaphore expiry (duration) सेट करके job conflict और deadlock से बचाव किया जा सकता है
• संबंधित tables
  • solid_queue_semaphores: concurrency limits को track करता है
  • solid_queue_blocked_executions: प्रतीक्षा कर रहे jobs को स्टोर करता है

Mission Control से monitoring

• Mission Control Jobs Rails 8 के लिए एक मुफ़्त open source dashboard है, जिसे /jobs path पर आसानी से mount किया जा सकता है
• मुख्य फीचर्स
  • real-time queue status, failed jobs tracking, retry/discard control
  • scheduled·recurring jobs timeline visualization
  • queue-wise throughput और metrics graphs
• यह SQL-based queries सपोर्ट करता है, इसलिए अतिरिक्त tools के बिना सीधे database में analysis किया जा सकता है

Sidekiq से SolidQueue में migration

• चरण 1: config.active_job.queue_adapter = :solid_queue सेट करें
• चरण 2: bundle add solid_queue के बाद rails solid_queue:install और db:migrate चलाएँ
• चरण 3: sidekiq.yml के cron schedule को recurring.yml में बदलें
• चरण 4: Procfile में jobs: bundle exec rake solid_queue:start जोड़ें
• चरण 5: Redis·Sidekiq से जुड़े gem हटा दें
• मौजूदा ActiveJob code बिना बदलाव के वैसे ही काम करेगा

जब Redis अब भी ज़रूरी हो

• प्रति सेकंड हज़ारों से अधिक लगातार job processing
• ऐसे real-time systems जहाँ 1ms से कम latency अनिवार्य हो
• complex pub/sub structure या advanced rate limiting·counter operations की ज़रूरत
• उदाहरण के लिए Shopify, प्रति सेकंड 833 requests और 1,172 worker processes चलाते हुए Redis infrastructure का उपयोग करता है

practical implementation guide

• Rails 8 में नया app बनाते समय SolidQueue·SolidCache·SolidCable अपने-आप configure हो जाते हैं
• config/database.yml में अलग queue database connection सेट करने की सिफ़ारिश की जाती है
• Mission Control authentication जोड़ें और /jobs route mount करें
• Procfile.dev में jobs: bundle exec rake solid_queue:start जोड़कर bin/dev चलाने से पूरा stack शुरू हो जाता है
• test jobs बनाने के बाद Mission Control में उनका status देखा जा सकता है

आम समस्याएँ और समाधान

• single database configuration भी संभव है, लेकिन इससे operational flexibility कम हो जाती है
• production environment में Mission Control के लिए authentication ज़रूर जोड़ें
• polling interval का डिफ़ॉल्ट मान scheduled jobs के लिए 1 सेकंड और immediate jobs के लिए 0.2 सेकंड है, जो ज़्यादातर apps के लिए उपयुक्त है
• ActionCable/Turbo Streams इस्तेमाल करते समय SolidCable को अलग DB connection पर सेट करना चाहिए

scalability और performance

• SolidQueue ज़्यादातर Rails apps में पर्याप्त रूप से scale कर सकता है
• PostgreSQL आधारित होने के कारण प्रति सेकंड 200~300 jobs प्रोसेस कर सकता है, और 37signals रोज़ 2 करोड़ jobs बिना Redis के संभालता है
• तुलना तालिका

  मद	Redis + Sidekiq	SolidQueue
  setup complexity	अलग service चाहिए	built-in DB का उपयोग
  query language	Redis commands	SQL
  monitoring	अलग dashboard	Mission Control
  failure scenarios	6 से अधिक	2
  throughput	हज़ारों jobs/second	200–300 jobs/second
  suitable for	99.9% apps	95% apps

निष्कर्ष

• Redis और Sidekiq बेहतरीन तकनीकें हैं, लेकिन ज़्यादातर Rails applications के लिए वे ज़रूरत से ज़्यादा complexity और cost लाते हैं
• SolidQueue एक single-database foundation पर operations को सरल, cost को कम और maintenance को अधिक efficient बनाता है
• Rails 8 के दौर में SolidQueue पर शिफ्ट डिफ़ॉल्ट विकल्प के रूप में सुझाया जाता है