वेब अॅपमध्ये background jobs कसे चालवायचे: queues, schedulers आणि cron

वेब अॅपमध्ये background jobs चालवण्यासाठी आधी कामाचे दोन प्रकार करा. Triggered jobs (स्वागत ईमेल पाठवा, upload प्रक्रिया करा) job queue मध्ये साठवता येतात, अनेकदा तुमच्या database मधील टेबल, आणि retries सह worker त्यांना हाताळतो. Scheduled jobs (रात्रीचा अहवाल, दर 15 मिनिटांनी आठवणी) वेळापत्रकावर चालणारे काहीतरी लागते: होस्टचे cron वैशिष्ट्य, किंवा संरक्षित endpoint ला कॉल करणारा बाह्य scheduler. jobs दोनदा चालल्या तरी सुरक्षित असाव्यात, अपयश नोंदवले जावे, आणि झोपू किंवा रीस्टार्ट होऊ शकणाऱ्या सर्व्हरमधील timer वर कधीही अवलंबून राहू नका.

हे मार्गदर्शक पर्याय, प्रत्येक कधी बसतो, आणि AI अॅप बिल्डरसह ते कसे सेट करायचे ते समजावते — scale to zero करणाऱ्या होस्ट्सवरही.

background job म्हणजे काय

जे काही संथ, अविश्वसनीय किंवा वापरकर्त्याच्या तात्काळ प्रतिसादासाठी आवश्यक नाही ते सर्व:

ईमेल, सूचना आणि पावत्या पाठवणे
इमेज रिसाईज करणे, व्हिडिओ transcode करणे, PDF तयार करणे
संथ तृतीय-पक्ष APIs ना कॉल करणे, लांब कामांसाठी AI मॉडेल्ससह
दुसऱ्या सिस्टीममधून डेटा इंपोर्ट किंवा sync करणे
रात्रीची साफसफाई, अहवाल आणि आठवणी

हे request च्या आत केल्यास पेजेस संथ आणि नाजूक होतात: ईमेल provider बंद असेल तर वापरकर्त्याचे साइन अप अयशस्वी होते. background मध्ये हलवल्यास वापरकर्त्याला झटपट प्रतिसाद मिळतो आणि job पुन्हा प्रयत्न करता येतो.

पर्याय

पर्याय	ते कसे चालते	फायदे	तोटे
त्याच प्रक्रियेत fire-and-forget	प्रतिसाद द्या, मग सर्व्हरमध्ये काम पुढे चालवा	सेटअप नाही	सर्व्हर थांबला तर हरवते; retries नाहीत
प्रक्रियेतील timer (`setInterval`, `setTimeout`)	चालू सर्व्हरमधील timer	अगदी सोपे	झोपलेले असताना चालत नाही; अनेक प्रतींमध्ये दुहेरी
database-backed queue	jobs rows म्हणून साठवलेले; worker त्यांना घेऊन चालवतो	तुमच्याकडे असलेला database वापरते; टिकाऊ; तपासणे सोपे	retries आणि locking तुम्ही बनवता; worker चालवण्यासाठी काहीतरी लागते
समर्पित queue (Redis-आधारित किंवा managed)	queue सेवा आणि workers	परिपक्व retry आणि scheduling फीचर्स	चालवायची आणि पैसे द्यायची आणखी एक सेवा
hosted job किंवा workflow सेवा	तृतीय-पक्ष तुमचे endpoints retries आणि वेळापत्रकासह कॉल करतो	scheduling आणि retries तुमच्यासाठी हाताळले जातात	विक्रेत्यावर अवलंबून; आणखी एक खाते आणि key
बाह्य scheduler जो endpoint कॉल करतो	दुसरीकडे असलेला टायमर ठरलेल्या वेळी HTTP request पाठवतो	कोणत्याही होस्टवर चालते, scale-to-zero सह देखील	किमान अंतर आणि विलंब; endpoint संरक्षित करा
होस्टचे built-in cron	प्लॅटफॉर्म वेळापत्रकावर command चालवतो	जिथे उपलब्ध तिथे सोपे	प्रत्येक होस्ट देत नाही

याचे एकच योग्य उत्तर नाही. छोट्या अॅपला अनेकदा फक्त database queue आणि बाह्य scheduler लागतो.

scale to zero होस्ट्स चित्र कसे बदलतात

अनेक आधुनिक होस्ट्स तुमचे अॅप कोणी वापरत नसताना झोपवतात आणि पुढच्या request ला जागे करतात. ते पैसे वाचवते, पण झोपलेला सर्व्हर कोणताही कोड चालवत नाही: timers फायर होत नाहीत आणि workers poll करत नाहीत. अशा होस्ट्सवर scheduled काम येणाऱ्या request ने सुरू झाले पाहिजे, आणि अशी request देण्याचा सोपा स्रोत म्हणजे बाह्य scheduler. प्रत्येक कॉल अॅप (आणि अनेकदा त्याचा database) जागे करतो, त्यामुळे दर मिनिटाला कॉल करणे दर 15 मिनिटांनी करण्यापेक्षा जास्त खर्च करते. गरजेला पुरेल असे सर्वात हळू वेळापत्रक निवडा.

पॅटर्न 1: database job queue

Triggered jobs साठी:

jobs टेबल बनवा: प्रकार, payload (JSON), स्थिती (pending, running, done, failed), attempts, run_after, last_error, वेळ-शिक्के.
काहीतरी घडते तेव्हा, ज्या बदलामुळे ते घडले त्याच transaction मध्ये job row घाला, जेणेकरून ते एकत्र यशस्वी किंवा अयशस्वी होतील.
worker वेळ आलेले jobs उचलतो, त्यांना running चिन्हांकित करतो, काम करतो आणि done चिन्हांकित करतो.
अपयशावर, attempts वाढवा, run_after नंतर सेट करा (उदाहरणार्थ 1, 5, मग 30 मिनिटे) आणि त्रुटी साठवा. कमाल मर्यादेनंतर failed चिन्हांकित करा आणि कोणाला तरी सूचित करा.

एकापेक्षा जास्त workers एकाच वेळी चालू शकत असतील तर jobs सुरक्षितपणे घ्यावे लागतात. Postgres वर SELECT ... FOR UPDATE SKIP LOCKED प्रत्येक worker ला वेगवेगळ्या rows घेऊ देते, एकमेकांशी न भिडता.

worker कोण चालवतो? नेहमी चालू सर्व्हरवर, वेगळ्या प्रक्रियेत loop. scale-to-zero होस्टवर, पॅटर्न 2 मधील scheduled endpoint प्रत्येक कॉलवर वेळ आलेल्या jobs ची batch प्रक्रिया करू शकतो.

पॅटर्न 2: तुमच्या अॅपला कॉल करणारा बाह्य scheduler

Scheduled jobs साठी:

POST /api/cron/send-reminders सारखा endpoint जोडा.
संरक्षित करा: header मध्ये गुप्त token मागा, जो दोन्ही बाजूंना secret म्हणून साठवलेला असेल, आणि इतर काहीही नाकारा.
idempotent बनवा: एकाच मिनिटात दोनदा चालवल्याने दोन स्मरणपत्रे जाऊ नयेत. काय पाठवले ते नोंदवा.
प्रत्येक कॉल लहान ठेवा: एक batch (म्हणा 100 items) प्रक्रिया करा, आणि उरलेले पुढील कॉल उचलेल.
एक scheduler त्याकडे निर्देश करा.

Scheduler पर्याय:

GitHub Actions scheduled workflows. GitHub च्या usage मर्यादेत मोफत. GitHub च्या docs नुसार सप्टेंबर 2026 पर्यंत, सर्वात लहान अंतर दर 5 मिनिटांनी एकदा आहे, व्यस्त वेळी (विशेषतः प्रत्येक तासाच्या सुरुवातीला) runs उशिरा होऊ शकतात, वेळापत्रक डीफॉल्टने UTC वापरते, आणि सार्वजनिक repository मधील scheduled workflows 60 दिवस repository क्रियाकलापाशिवाय असतील तर अक्षम होतात.
Hosted cron सेवा. अनेक सेवा अस्तित्वात आहेत ज्यांचे एकमेव काम वेळापत्रकावर URL ला कॉल करणे आहे. अवलंबून राहण्याआधी विश्वासार्हता, किमान अंतर आणि alerts तपासा.
तुमच्या cloud provider चा scheduler. तुम्ही आधीच मोठा cloud provider वापरत असाल तर त्याचा managed scheduler HTTPS endpoint ला कॉल करू शकतो.
hosted job किंवा workflow सेवा. हे scheduling, queues आणि retries एकत्र करतात, आणि प्रत्येक पायरीसाठी तुमच्या endpoints ना कॉल करतात. किंमत आणि मर्यादा प्रत्येक विक्रेत्याच्या साइटवर तपासा.

पॅटर्न 3: provider ला ते करू द्या

कधीकधी सर्वोत्तम background job म्हणजे कोणताच नसतो:

पेमेंट्स. Stripe अयशस्वी subscription पेमेंट्स पुन्हा प्रयत्न करतो आणि webhooks पाठवतो; तुम्ही polling करण्याऐवजी प्रतिक्रिया देता. webhook म्हणजे काय पहा.
ईमेल. संदेश तुम्ही दिल्यानंतर providers डिलिव्हरी queue करतात आणि पुन्हा प्रयत्न करतात.
मोठ्या प्रमाणावरील AI काम. OpenAI आणि Anthropic तातडीच्या नसलेल्या requests साठी batch APIs देतात, जे तुम्ही सबमिट करता आणि नंतर गोळा करता.

तुमच्या AI बिल्डरला देण्यासाठी prompts

queue साठी:

आमच्या database मध्ये jobs टेबल वापरून background job queue जोडा (प्रकार, payload JSON, status, attempts, run_after, last_error). वापरकर्ता साइन अप करतो तेव्हा, ईमेल थेट न पाठवता त्याच transaction मध्ये send_welcome_email job घाला. processJobs(limit) फंक्शन जोडा जे वेळ आलेले jobs SELECT ... FOR UPDATE SKIP LOCKED ने घेते, चालवते, आणि अपयश 1, 5 आणि 30 मिनिटांनंतर पुन्हा प्रयत्न करते, 4 प्रयत्नांनंतर failed चिन्हांकित करते.

scheduled trigger साठी:

POST /api/cron/tick जोडा, जो CRON_SECRET या secret मधील bearer token ने संरक्षित आहे; त्याशिवाय येणारी कोणतीही request नाकारा. प्रत्येक कॉल processJobs(100) चालवतो आणि पुढील 24 तासांत येणारी बुकिंग स्मरणपत्रे पाठवतो जी अजून पाठवली गेलेली नाहीत, पाठवलेली स्मरणपत्रे नोंदवून जेणेकरून काहीही दोनदा जाणार नाही. काय चालले त्याचा JSON सारांश परत करा. मग एक GitHub Actions workflow लिहा जो दर 15 मिनिटांनी हा endpoint कॉल करतो, URL आणि token repository secrets मधून वाचत.

सामान्य चुका

setInterval वर अवलंबून राहणे. सर्व्हर झोपला किंवा रीस्टार्ट झाला तर ते शांतपणे थांबते, आणि दोन प्रती चालल्या तर दुप्पट होते.
संरक्षित नसलेला cron endpoint. तो कोणाला सापडला तर तो तुमचे jobs, किंवा तुमचे ईमेल बिल, ट्रिगर करू शकतो.
idempotent नसलेले jobs. retries आणि डुप्लिकेट scheduler कॉल होतीलच. त्यासाठी डिझाइन करा.
अपयशाची दृश्यमानता नाही. आठवडाभर शांतपणे अपयशी होणारे job, मोठ्याने अपयशी होणाऱ्या job पेक्षा वाईट आहे. त्रुटी नोंदवा आणि वारंवार अपयशावर alert करा.
एकाच request मध्ये लांब runs. requests timeout होतात. batch मध्ये प्रक्रिया करा.
खूप वारंवार scheduling. scale-to-zero होस्टवर प्रत्येक कॉल अॅप जागे करतो आणि त्याचे बिल वाढवतो. अंतर गरजेशी जुळवा.
टाइम झोन. “सकाळी 9” तुमच्या scheduler (अनेकदा UTC) आणि वापरकर्त्यांसाठी वेगळे अर्थ देते. वेळा UTC मध्ये साठवा आणि प्रत्येक वापरकर्त्यासाठी रूपांतर करा.
workflow फाइलमध्ये secrets. tokens scheduler च्या secret store मध्ये ठेवा. API keys सुरक्षित कशा ठेवायच्या पहा.

Checklist

संथ काम वापरकर्त्याच्या requests बाहेर हलवले आहे
jobs फक्त मेमरीत नाही तर टिकाऊ साठवले आहेत
वाढत्या विलंबासह retries आणि कमाल मर्यादा
प्रत्येक job दोनदा चालवणे सुरक्षित आहे
scheduled endpoint गुप्त token ने संरक्षित आहे
प्रत्येक run मर्यादित batch प्रक्रिया करतो
अयशस्वी jobs दृश्यमान आहेत, alerts सह
होस्टिंग खर्च लक्षात घेऊन schedule अंतर निवडले आहे
वेळा UTC मध्ये साठवल्या आहेत

Mythex मधील background jobs

Mythex च्या documentation मध्ये scheduled किंवा cron jobs चे वर्णन नाही, आणि प्रकाशित अॅप्स आणि त्यांचे databases निष्क्रिय असताना झोपतात आणि पुढच्या request ला जागे होतात (पहा Hosting limits). त्यामुळे तुमच्या अॅपमधील timers वर अवलंबून राहू नका. जी पद्धत काम करते ती वरीलप्रमाणे आहे: एजंटला jobs टेबल आणि token-संरक्षित endpoint मागा, मग बाह्य scheduler तुमच्या प्रकाशित URL कडे निर्देशित करा. token प्रोजेक्ट secret म्हणून साठवा, आणि लक्षात ठेवा की प्रत्येक wake-up अॅप आणि database जागे असलेल्या वेळेसाठी क्रेडिट्स खर्च करते, त्यामुळे योग्य अंतर निवडा. तुमच्या अॅपला यासाठी API backend हवा असेल तर REST API backend recipe सुरुवातीचा मुद्दा आहे, आणि REST API कसे बनवायचे endpoints डिझाइन करण्याबद्दल सांगते. जर सतत चालणारे workers किंवा bots हेच तुमच्या प्रॉडक्टचे केंद्र असतील, तर सतत प्रक्रियांसाठी बनवलेला होस्ट अधिक योग्य असू शकतो.

प्रश्न

background job म्हणजे काय?

background job म्हणजे वापरकर्ता ज्या request ची वाट पाहत आहे त्याच्या बाहेर अॅप करत असलेले काम, जसे ईमेल पाठवणे, इमेज रिसाईज करणे, अहवाल तयार करणे किंवा डेटा sync करणे. वापरकर्त्याला झटपट प्रतिसाद मिळतो, आणि job वेगळे चालते आणि अयशस्वी झाल्यास पुन्हा प्रयत्न करता येतो.

माझ्या होस्टकडे cron नसेल तर scheduled task कसे चालवू?

एक संरक्षित endpoint जोडा जो काम करतो, मग एक बाह्य scheduler ठरलेल्या वेळापत्रकावर त्याला कॉल करू द्या. पर्यायांमध्ये scheduled GitHub Actions workflow, hosted cron सेवा, किंवा तुमच्या cloud provider चा scheduler येतो. endpoint ला गुप्त token ने संरक्षित करा.

scheduled jobs साठी setInterval किंवा setTimeout वापरू शकतो का?

फक्त लहान, कमी महत्त्वाच्या कामांसाठी, नेहमी चालू असलेल्या सर्व्हरवर. सर्व्हर रीस्टार्ट झाला, शून्यावर स्केल झाला किंवा अनेक प्रती चालल्या तर timers हरवतात किंवा एकापेक्षा जास्त वेळा चालतात. scheduled काम database मध्ये साठवा किंवा scheduler वापरा.

Mythex cron jobs ना सपोर्ट करते का?

Mythex च्या documentation मध्ये scheduled किंवा cron jobs चे वर्णन नाही, आणि प्रकाशित अॅप्स निष्क्रिय असताना झोपतात. विश्वासार्ह पद्धत म्हणजे तुमच्या अॅपमधील संरक्षित endpoint ला बाह्य scheduler कडून कॉल करवणे, जे अॅप जागे करून काम चालवते.