वेब ऐप में बैकग्राउंड जॉब्स कैसे चलाएं: queues, schedulers और cron

वेब ऐप में बैकग्राउंड जॉब्स चलाने के लिए पहले काम को दो प्रकारों में बाँटें। ट्रिगर्ड जॉब्स (स्वागत ईमेल भेजना, अपलोड प्रोसेस करना) को job queue में सहेजा जा सकता है, जो अक्सर आपके डेटाबेस की एक टेबल होती है, और retries वाला worker उन्हें संभालता है। शेड्यूल्ड जॉब्स (रात की रिपोर्ट, हर 15 मिनट पर याद दिलाने) को कुछ ऐसा चाहिए जो तय समय पर चले: होस्ट का cron फ़ीचर, या कोई बाहरी scheduler जो आपके ऐप के सुरक्षित एंडपॉइंट को कॉल करे। जॉब्स को हमेशा दोबारा चलाने पर सुरक्षित बनाएं, विफलताएँ रिकॉर्ड करें, और उस सर्वर के टाइमर पर कभी भरोसा न करें जो सो सकता है या रीस्टार्ट हो सकता है।

यह गाइड विकल्प समझाती है, बताती है कि हर एक कब फ़िट होता है, और AI ऐप बिल्डर के साथ, शून्य तक scale होने वाले होस्ट्स पर भी, उन्हें कैसे सेट करें।

बैकग्राउंड जॉब किसे कहते हैं

कोई भी ऐसा काम जो धीमा, अविश्वसनीय हो या यूज़र के तुरंत जवाब के लिए ज़रूरी न हो:

• ईमेल, सूचनाएँ और रसीदें भेजना
• इमेज का आकार बदलना, वीडियो ट्रांसकोड करना, PDF बनाना
• धीमे तीसरे-पक्ष APIs को कॉल करना, जिनमें लंबे कामों के लिए AI मॉडल भी शामिल हैं
• किसी दूसरे सिस्टम से डेटा इम्पोर्ट या सिंक करना
• रात की सफ़ाई, रिपोर्ट और याद दिलाने वाले काम

अगर यह काम अनुरोध के अंदर किया जाए, तो पेज धीमे और नाज़ुक हो जाते हैं: अगर ईमेल प्रोवाइडर डाउन है, तो यूज़र का साइनअप विफल हो जाता है। इसे बैकग्राउंड में ले जाने से यूज़र को तुरंत जवाब मिलता है और जॉब दोबारा चलाया जा सकता है।

विकल्प

कोई एक सही उत्तर नहीं है। एक छोटे ऐप को अक्सर सिर्फ़ एक डेटाबेस queue और एक बाहरी scheduler चाहिए।

शून्य तक scale होने वाले होस्ट्स से तस्वीर क्यों बदलती है

कई आधुनिक होस्ट आपके ऐप को तब सुला देते हैं जब कोई उसका इस्तेमाल नहीं कर रहा, और अगले अनुरोध पर जगा देते हैं। इससे पैसे बचते हैं, पर सोता हुआ सर्वर कोई कोड नहीं चलाता: टाइमर नहीं चलते और workers poll नहीं करते। ऐसे होस्ट्स पर शेड्यूल्ड काम को आने वाले अनुरोध से शुरू होना होता है, और उस अनुरोध का सबसे आसान स्रोत एक बाहरी scheduler है। हर कॉल ऐप (और अक्सर उसके डेटाबेस) को जगाती है, इसलिए हर मिनट कॉल करना हर 15 मिनट पर कॉल करने से ज़्यादा महंगा है। ज़रूरत पूरी करने वाला सबसे धीमा शेड्यूल चुनें।

पैटर्न 1: डेटाबेस job queue

ट्रिगर्ड जॉब्स के लिए:

1. एक jobs टेबल बनाएं: प्रकार, payload (JSON), स्थिति (pending, running, done, failed), attempts, run_after, last_error, टाइमस्टैम्प।
2. जब कुछ होता है, तो उसी ट्रांज़ैक्शन में एक job row डालें जिसने उसे पैदा किया, ताकि वे साथ सफल या विफल हों।
3. एक worker देय जॉब्स उठाता है, उन्हें running चिह्नित करता है, काम करता है और done चिह्नित करता है।
4. विफलता पर attempts बढ़ाएं, run_after बाद का सेट करें (जैसे 1, 5, फिर 30 मिनट) और एरर सहेजें। अधिकतम के बाद उसे failed चिह्नित करें और किसी को सूचित करें।

अगर एक से ज़्यादा worker एक साथ चल सकते हैं, तो जॉब्स सुरक्षित रूप से claim होने चाहिए। Postgres पर SELECT ... FOR UPDATE SKIP LOCKED हर worker को अलग पंक्तियाँ claim करने देता है, बिना टकराए।

Worker को कौन चलाता है? हमेशा चालू सर्वर पर, एक अलग प्रोसेस में एक loop। शून्य तक scale होने वाले होस्ट पर, पैटर्न 2 का शेड्यूल्ड एंडपॉइंट हर कॉल पर देय जॉब्स का एक बैच प्रोसेस कर सकता है।

पैटर्न 2: बाहरी scheduler जो आपके ऐप को कॉल करे

शेड्यूल्ड जॉब्स के लिए:

1. एक एंडपॉइंट जोड़ें, जैसे POST /api/cron/send-reminders।
2. उसे सुरक्षित करें: एक header में सीक्रेट टोकन माँगें, जो दोनों तरफ़ सीक्रेट के रूप में रखा हो, और बाकी सब ठुकरा दें।
3. उसे idempotent बनाएं: उसी मिनट में दो बार चलने पर दो याद दिलाने नहीं जाने चाहिए। जो भेजा गया उसे रिकॉर्ड करें।
4. हर कॉल को छोटा रखें: एक बैच (मान लें 100 आइटम) प्रोसेस करें और बाकी अगली कॉल पर छोड़ें।
5. किसी scheduler को उस पर इंगित करें।

Scheduler के विकल्प:

• GitHub Actions शेड्यूल्ड workflows। GitHub की usage सीमा के भीतर मुफ़्त। सितंबर 2026 तक GitHub के दस्तावेज़ कहते हैं कि सबसे छोटा अंतराल हर 5 मिनट है, व्यस्त समय में (खासकर हर घंटे की शुरुआत में) रन में देरी हो सकती है, शेड्यूल्स डिफ़ॉल्ट रूप से UTC इस्तेमाल करते हैं, और सार्वजनिक रिपॉज़िटरी में शेड्यूल्ड workflows 60 दिन रिपॉज़िटरी गतिविधि न होने पर बंद हो जाते हैं।
• होस्टेड cron सर्विसेज़। कई सर्विसेज़ हैं जिनका एकमात्र काम तय समय पर एक URL कॉल करना है। उन पर निर्भर होने से पहले विश्वसनीयता, न्यूनतम अंतराल और अलर्टिंग जाँचें।
• आपके क्लाउड प्रोवाइडर का scheduler। अगर आप पहले से एक बड़ा क्लाउड प्रोवाइडर इस्तेमाल करते हैं, तो उसका managed scheduler होगा जो HTTPS एंडपॉइंट को कॉल कर सकता है।
• होस्टेड job या workflow सर्विस। ये scheduling, queues और retries को मिलाते हैं, और हर चरण के लिए आपके एंडपॉइंट्स को कॉल करते हैं। हर विक्रेता की साइट पर मूल्य और सीमाएँ तुलना करें।

पैटर्न 3: प्रोवाइडर को करने दें

कभी-कभी सबसे अच्छा बैकग्राउंड जॉब कोई होता ही नहीं:

• पेमेंट। Stripe विफल सब्सक्रिप्शन पेमेंट दोबारा करता है और webhooks भेजता है; आप पोल करने के बजाय उन पर प्रतिक्रिया देते हैं। देखें webhook क्या है।
• ईमेल। प्रोवाइडर संदेश सौंपे जाने के बाद डिलीवरी को queue और retry करते हैं।
• बल्क AI काम। OpenAI और Anthropic गैर-ज़रूरी अनुरोधों के लिए batch APIs देते हैं, जिन्हें आप जमा करते हैं और बाद में लेते हैं।

अपने AI बिल्डर को देने के लिए प्रॉम्प्ट

queue के लिए:

हमारे डेटाबेस में एक jobs टेबल का इस्तेमाल करके बैकग्राउंड job queue जोड़ो (प्रकार, payload JSON, status, attempts, run_after, last_error)। जब कोई यूज़र साइनअप करे, तो ईमेल तुरंत भेजने के बजाय उसी ट्रांज़ैक्शन में एक send_welcome_email job डालो। एक processJobs(limit) फ़ंक्शन जोड़ो जो देय jobs को SELECT ... FOR UPDATE SKIP LOCKED से claim करे, उन्हें चलाए, और विफलताओं को 1, 5 और 30 मिनट बाद दोबारा कोशिश करे, और 4 प्रयासों के बाद failed चिह्नित करे।

शेड्यूल्ड ट्रिगर के लिए:

POST /api/cron/tick जोड़ो जो CRON_SECRET सीक्रेट से आए bearer token से सुरक्षित हो; उसके बिना कोई भी अनुरोध ठुकराओ। हर कॉल processJobs(100) चलाए और अगले 24 घंटों में देय बुकिंग रिमाइंडर भेजे जो अभी तक नहीं भेजे गए, और भेजे गए रिमाइंडर रिकॉर्ड करे ताकि कुछ दो बार न जाए। चली गई चीज़ों का JSON सारांश लौटाओ। फिर एक GitHub Actions workflow लिखो जो हर 15 मिनट पर इस एंडपॉइंट को कॉल करे, URL और टोकन repository secrets से पढ़ते हुए।

आम गलतियाँ

• setInterval पर भरोसा। सर्वर सोने या रीस्टार्ट होने पर यह चुपचाप रुक जाता है, और दो प्रतियाँ चलने पर दोगुना हो जाता है।
• बिना सुरक्षा का cron एंडपॉइंट। जो भी उसे ढूँढे, वह आपके जॉब्स या आपके ईमेल बिल को चालू कर सकता है।
• ऐसे जॉब्स जो idempotent नहीं हैं। retries और दोहरी scheduler कॉल होंगी ही। उसी के लिए डिज़ाइन करें।
• विफलता की दृश्यता न होना। एक जॉब जो एक हफ़्ते चुपचाप विफल होता रहे, वह उससे बुरा है जो ज़ोर से विफल हो। एरर लॉग करें और बार-बार विफलता पर अलर्ट करें।
• एक ही अनुरोध में लंबे रन। अनुरोध टाइम आउट होते हैं। बैच में प्रोसेस करें।
• बहुत बार शेड्यूल करना। शून्य तक scale होने वाले होस्ट पर हर कॉल ऐप को जगाती और बिल बढ़ाती है। अंतराल को असल ज़रूरत से मिलाएं।
• समय क्षेत्र। “सुबह 9 बजे” आपके scheduler (अक्सर UTC) और आपके यूज़र्स के लिए अलग अर्थ रखता है। समय UTC में सहेजें और हर यूज़र के हिसाब से बदलें।
• workflow फ़ाइल में सीक्रेट। टोकन scheduler के सीक्रेट स्टोर में रखें। देखें API keys कैसे सुरक्षित रखें।

चेकलिस्ट

• धीमा काम यूज़र अनुरोधों से बाहर ले जाया गया
• जॉब्स टिकाऊ रूप से सहेजे गए हैं, सिर्फ़ मेमोरी में नहीं
• बढ़ते अंतराल और अधिकतम सीमा के साथ retries
• हर जॉब दोबारा चलाने पर सुरक्षित है
• शेड्यूल्ड एंडपॉइंट एक सीक्रेट टोकन से सुरक्षित है
• हर रन एक सीमित बैच प्रोसेस करता है
• विफल जॉब्स दिखते हैं, अलर्ट के साथ
• शेड्यूल अंतराल होस्टिंग खर्च को ध्यान में रखकर चुना गया
• समय UTC में सहेजा गया

Mythex में बैकग्राउंड जॉब्स

Mythex के दस्तावेज़ शेड्यूल्ड या cron jobs का वर्णन नहीं करते, और पब्लिश्ड ऐप्स व उनके डेटाबेस निष्क्रिय होने पर सो जाते हैं और अगले अनुरोध पर जागते हैं (देखें Hosting limits)। इसलिए अपने ऐप के अंदर टाइमर पर भरोसा न करें। जो तरीका काम करता है वह ऊपर वाला है: एजेंट से एक jobs टेबल और एक टोकन-सुरक्षित एंडपॉइंट माँगें, फिर अपने पब्लिश्ड URL की ओर एक बाहरी scheduler इंगित करें। टोकन को प्रोजेक्ट सीक्रेट के रूप में सहेजें, और याद रखें कि हर wake-up उतने समय के लिए क्रेडिट खर्च करता है जितनी देर ऐप और डेटाबेस जागे रहते हैं, इसलिए समझदार अंतराल चुनें। अगर आपके ऐप को इसके लिए API बैकएंड चाहिए, तो REST API backend रेसिपी एक शुरुआत है, और REST API कैसे बनाएं एंडपॉइंट्स डिज़ाइन करना समझाता है। अगर आपके प्रोडक्ट का मूल ही हमेशा चलने वाले workers या bots हैं, तो लगातार चलने वाली प्रोसेस के लिए बना होस्ट बेहतर हो सकता है।

सवाल