Express रूट के अंदर इमेज रिसाइजिंग चलाना मुसीबत को दावत देने जैसा है। एक यूजर दस मेगाबाइट की फोटो अपलोड करता है, आपका सर्वर पिक्सेल प्रोसेस करना शुरू करता है, और तीस सेकंड बाद रिक्वेस्ट टाइम आउट हो जाती है। बैकग्राउंड जॉब क्यूज़ (Background job queues) ठीक इसी तरह की परेशानियों को रोकने के लिए बनाए गए हैं। Node.js इकोसिस्टम में, Bull और BullMQ, Redis के माध्यम से एसिंक्रोनस (asynchronous) काम संभालने के लिए दो दिग्गज बन गए हैं। उनकी बुनियादी संरचना समान है, लेकिन दर्शन (philosophy) और दैनिक उपयोग (ergonomics) के मामले में वे काफी अलग हैं। सही चुनाव करना महत्वपूर्ण है क्योंकि बाद में स्विच करना केवल एक साधारण पैकेज अपडेट नहीं है।
साझा आधार (The Shared Foundation)
दोनों लाइब्रेरीज़ अपने आधार के रूप में Redis का उपयोग करती हैं। Redis एटॉमिक ऑपरेशन्स, डिलेड जॉब्स के लिए सॉर्टेड सेट्स, और इवेंट्स के लिए पब/सब (pub/sub) को संभालता है। यदि आप पहले से ही कैशिंग या सेशन्स के लिए Redis चला रहे हैं, तो नया जॉब क्यू जोड़ने के लिए नए इन्फ्रास्ट्रक्चर की आवश्यकता नहीं है। Bull और BullMQ दोनों प्रायोरिटीज़, बैकऑफ़ के साथ रिट्राइज़, कॉनकरेंसी कंट्रोल और रिपीट करने योग्य जॉब्स का समर्थन करते हैं। यह समानता चुनाव को आसान बनाने के बजाय और कठिन बना देती है। आप केवल फीचर्स की चेकलिस्ट के आधार पर फैसला नहीं ले सकते। इसके बजाय, आपको यह देखना होगा कि प्रत्येक लाइब्रेरी आपसे अपने कोड को कैसे स्ट्रक्चर करवाना चाहती है।
Bull: परखा हुआ अनुभवी (The Battle-Tested Veteran)
Bull सालों से मौजूद है और हजारों प्रोडक्शन एप्लिकेशन में चल रहा है। यह काम करता है। इसका API सब कुछ एक ही Queue इंस्टेंस में समेट देता है। आप इसे इंस्टेंटिएट करते हैं, एक प्रोसेसिंग फंक्शन परिभाषित करते हैं, और उसी ऑब्जेक्ट पर इवेंट्स को सुनते हैं। यदि आप पुराने Node.js पैटर्न से आते हैं, तो यह मोनोलिथिक डिज़ाइन जाना-पहचाना लगेगा। वे कोडबेस जो व्यापक async/await से पहले के हैं, Bull के साथ स्वाभाविक रूप से फिट बैठते हैं क्योंकि यह कॉलबैक्स और शुरुआती Redis क्लाइंट्स के साथ विकसित हुआ है।
इसका नुकसान 'टाइट कपलिंग' (tight coupling) है। जब आपका API सर्वर एक जॉब बनाता है, तो वह उसी Queue ऑब्जेक्ट को इम्पोर्ट करता है जिसमें वर्कर लॉजिक होता है। व्यवहार में, इसका मतलब है कि आपका वेब प्रोसेस उन डिपेंडेंसीज़ को भी साथ खींच लाता है जिन्हें वह कभी निष्पादित (execute) नहीं करता। यह कोई घातक दोष नहीं है, लेकिन यह क्लीन आर्किटेक्चर में बाधा डालता है। सरल वर्कलोड के लिए, आपको शायद कभी पता न चले। लेकिन दर्जनों मॉड्यूल वाली बड़ी टीमों के लिए, यह समस्या बढ़ती जाती है।
BullMQ: शुरुआत से किया गया पुनर्निर्माण (A Ground-Up Rebuild)
BullMQ इसका आधिकारिक उत्तराधिकारी है। इसे पहले दिन से ही TypeScript में फिर से लिखा गया था, इसलिए टाइप्स (types) जावास्क्रिप्ट सोर्स पर बाद में जोड़ा गया कोई विचार नहीं हैं। इसका API ज़िम्मेदारियों को अलग-अलग क्लासेस में बाँट देता है। Queue जॉब्स जोड़ने को संभालता है। Worker उन्हें प्रोसेस करने को संभालता है। QueueEvents ऑब्ज़र्वेबिलिटी (observability) को संभालता है। यह अलगाव दर्शाता है कि आधुनिक डिस्ट्रीब्यूटेड सिस्टम वास्तव में कैसे काम करते हैं। आपके API पॉड्स को केवल Queue क्लास और एक Redis कनेक्शन की आवश्यकता होती है। आपके वर्कर पॉड्स Worker क्लास को इम्पोर्ट करते हैं। इसकी सीमा केवल वैचारिक (conceptual) नहीं, बल्कि भौतिक (physical) है।
बड़ी टीमों में यह बदलाव बहुत काम आता है। एक डेवलपर जो नया फीचर शिप कर रहा है, वह यह जाने बिना भी जॉब एनक्यू (enqueue) कर सकता है कि प्रोसेसर किस फ़ाइल में है। कंपाइलर रनटाइम के बजाय जॉब डेटा और हैंडलर्स के बीच टाइप मिसमैच को जल्दी पकड़ लेता है। आधुनिक Node.js में इसका async/await API भी स्वाभाविक लगता है। आपको पुराने नियमों (legacy conventions) से जूझना नहीं पड़ेगा।
जॉब फ्लो: हैक्स से लेकर फर्स्ट-क्लास सिटीजन तक (Job Flows: From Hacks to First-Class Citizens)
मल्टी-स्टेप वर्कफ़्लो दोनों लाइब्रेरीज़ के बीच सबसे बड़ा अंतर दिखाते हैं।
मान लीजिए कि आप एक ई-कॉमर्स इनवॉइसिंग पाइपलाइन बना रहे हैं। एक ग्राहक चेकआउट करता है। आपको इन्वेंट्री रिजर्व करने, कार्ड चार्ज करने, PDF जेनरेट करने और ईमेल भेजने की आवश्यकता है। Bull के साथ, इन चरणों को जोड़ने का मतलब है मैन्युअल हिसाब-किताब। हो सकता है कि आपका एक प्रोसेसर अगले जॉब को फायर करे, और स्टेट को Redis या भारी डेटा पेलोड के माध्यम से पास करे। आप पैरेंट-चाइल्ड समन्वय (coordination) खुद लिखते हैं। यह तब तक काम करता है जब तक कि कुछ गलत न हो जाए। रिट्राइ लॉजिक उलझ जाता है। यदि PDF स्टेप विफल हो जाता है, तो चार्ज को वापस लेने (unwinding) के लिए कस्टम कंपंसेशन कोड की आवश्यकता होती है जिसे गलत करना आसान है।
BullMQ FlowProducer पेश करता है। आप जॉब्स का एक ट्री (tree) परिभाषित करते हैं जहाँ पैरेंट अपने बच्चों (children) का स्वचालित रूप से इंतज़ार करते हैं। इनवॉइसिंग के उदाहरण में, आप finalize-order नामक एक रूट जॉब बनाते हैं जिसमें तीन चाइल्ड जॉब्स होते हैं: reserve-inventory, charge-payment, और generate-pdf। आप ईमेल नोटिफिकेशन को PDF जॉब का चाइल्ड बना सकते हैं। Redis ग्राफ स्ट्रक्चर को स्टोर करता है। पैरेंट तभी सक्रिय होता है जब हर डिपेंडेंसी सफल हो जाती है। यदि एक भी चाइल्ड विफल होता है, तो पूरा ब्रांच रुक जाता है। आपको पोलिंग लूप या रिकर्सिव जॉब स्पॉनर्स लिखने की ज़रूरत नहीं है। यह केवल सिंटैक्टिक शुगर (syntactic sugar) नहीं है। यह आपके बिजनेस लॉजिक को मॉडल करने के तरीके को बदल देता है।
रेट लिमिटिंग: एक भारी औज़ार बनाम एक सटीक उपकरण (Rate Limiting: Blunt Instrument vs. Scalpel)
दोनों लाइब्रेरीज़ थ्रूपुट (throughput) को नियंत्रित कर सकती हैं, लेकिन उनकी बारीकी (granularity) में बहुत अंतर है।
Bull प्रति क्यू (queue) रेट लिमिट लागू करता है। यदि आप एक क्यू को प्रति सेकंड सौ जॉब्स प्रोसेस करने के लिए सेट करते हैं, तो वह सीमा क्यू के हर जॉब पर समान रूप से लागू होती है। यह एक समान (homogeneous) वर्कलोड के लिए ठीक है। लेकिन मल्टी-टेनेंट (multitenant) SaaS प्लेटफॉर्म्स में यह समस्या पैदा करता है। कल्पना कीजिए कि एक 'नॉइज़ी' (noisy) कस्टमर एक साझा क्यू में लाखों वेबहुक डिलीवरी डाल देता है। Bull की क्यू-लेवल लिमिट का मतलब है कि आप बाकी सभी को धीमा किए बिना उस विशेष टेनेंट को धीमा नहीं कर सकते। आपके विकल्प कठिन हैं। या तो प्रत्येक कस्टमर के लिए अलग-अलग Redis क्यू बनाएं और उन्हें डायनामिक रूप से मैनेज करें, या फिर इस असमानता को स्वीकार करें।
BullMQ ग्रुप-आधारित रेट लिमिटिंग जोड़ता है। आप प्रत्येक जॉब को एक ग्रुप की (group key) के साथ टैग करते हैं, जो आमतौर पर एक टेनेंट या यूजर आईडी होती है, और प्रति ग्रुप लिमिट निर्धारित करते हैं। वही क्यू सभी टेनेंट्स के लिए जॉब्स प्रोसेस करती है, लेकिन शेड्यूलर प्रत्येक ग्रुप को स्वतंत्र रूप से नियंत्रित (throttle) करता है। कस्टमर A की अचानक बढ़ी हुई गतिविधि (burst) से कस्टमर B के काम में बाधा नहीं आती। आप क्यू के अनियंत्रित विस्तार (queue sprawl) से बचते हैं और अपने Redis keyspace को व्यवस्थित रखते हैं। उन प्लेटफॉर्म्स के लिए जहाँ 'नॉइज़ी-नेबर' (noisy-neighbor) की समस्या है, यह अकेला फीचर माइग्रेशन को सही ठहरा सकता है।
व्यवहार में स्वच्छ आर्किटेक्चर (Cleaner Architecture in Practice)
क्यू (Queue) और वर्कर (Worker) का अलगाव तब तक सूक्ष्म लगता है जब तक आप प्रोडक्शन इंसिडेंट को डीबग नहीं करते। Bull के साथ, रूट हैंडलर्स (route handlers) के भीतर जॉब क्रिएशन कोड देखना आम बात है, जो भारी प्रोसेसिंग डिपेंडेंसीज़ (dependencies) को भी इम्पोर्ट करते हैं। BullMQ आपको यह तय करने के लिए मजबूर करता है कि काम कहाँ होगा। आपके वेब सर्वर हल्के (lean) रहते हैं। आपके वर्कर कंटेनर्स भारी लाइब्रेरीज़, इमेज प्रोसेसर, या हेडलेस ब्राउज़र्स को बंडल करते हैं। यदि मेमोरी लीक (memory leak) दिखाई देता है, तो आप जानते हैं कि किस प्रोसेस टाइप को प्रोफाइल करना है। इसका मेंटल मॉडल Celery या Sidekiq जैसे सिस्टम के करीब है।
चुनाव करना (Making the Choice)
यदि आप बिल्कुल नए सिरे से शुरुआत कर रहे हैं, तो BullMQ से शुरू करें। इसके TypeScript डेफिनिशन सटीक और पूर्ण हैं। जॉब फ्लो (job flows) ऑर्केस्ट्रेशन कोड की भारी मात्रा को खत्म कर देते हैं। ग्रुप रेट लिमिटिंग समस्याओं के शुरू होने से पहले ही निष्पक्षता (fairness) की समस्याओं को हल कर देती है। इसका async/await API एकदम नेटिव (native) महसूस होता है। किसी नए प्रोजेक्ट (greenfield project) के लिए पुरानी लाइब्रेरी चुनने का कोई खास कारण नहीं है।
यदि Bull पहले से ही काम कर रहा है, तो उसी पर बने रहें। माइग्रेशन में समय लगता है और स्थिरता (stability) का जोखिम होता है। यदि आपके जॉब्स सरल और स्वतंत्र हैं, तो आप उन फीचर्स को मिस नहीं कर रहे हैं जिनकी आपको वास्तव में आवश्यकता है। एक क्यू जो पासवर्ड रीसेट ईमेल भेजती है और अवतार रीसाइज करती है, उसे फ्लो ग्राफ की आवश्यकता नहीं होती। सैद्धांतिक शुद्धता (theoretical purity) के लिए चलते हुए कोड को फिर से लिखना इंजीनियरिंग नहीं है। यह केवल एक शौक (hobbyism) है।
माइग्रेशन का वास्तविकता परीक्षण (Migration Reality Check)
यदि आप स्विच करते हैं, तो इसे इंफ्रास्ट्रक्चर परिवर्तन के रूप में मानें, न कि कोड रिफैक्टर (code refactor) के रूप में। Bull और BullMQ अलग-अलग Redis की स्कीमा (key schemas) का उपयोग करते हैं। वे एक-दूसरे के जॉब डेटा या स्टेट को नहीं पढ़ सकते। आप केवल एक फीचर फ्लैग बदलकर यह उम्मीद नहीं कर सकते कि पुराने जॉब्स पूरे हो जाएंगे। आपको प्रत्येक मौजूदा क्यू को पूरी तरह खाली (drain to zero) करना होगा, नए वर्कर तैनात करने होंगे, और BullMQ के साथ एनक्यू (enqueueing) शुरू करना होगा। एक मेंटेनेंस विंडो या ब्लू-ग्रीन डिप्लॉयमेंट (blue-green deployment) की योजना बनाएं जहाँ पुराने वर्कर लेगेसी क्यू का उपयोग करें जबकि नए वर्कर नई क्यू को संभालें।