વેબ એપમાં background jobs કેવી રીતે ચલાવવા: Queues, Schedulers અને Cron

વેબ એપમાં background jobs ચલાવવા માટે, પહેલા કામને બે પ્રકારમાં વહેંચો. Triggered jobs (સ્વાગત ઇમેઇલ મોકલવો, upload પ્રોસેસ કરવો) job queue માં સાચવી શકાય છે, જે ઘણી વાર તમારા database માં એક table હોય છે, અને retries સાથે worker તેને સંભાળે છે. Scheduled jobs (રાત્રિનો રિપોર્ટ, દર 15 મિનિટે યાદ અપાવવું) ને સમયપત્રક પર ચાલનારી કોઈ વસ્તુ જોઈએ: હોસ્ટની cron સુવિધા, અથવા external scheduler જે તમારી એપમાં સુરક્ષિત endpoint ને બોલાવે. jobs ને હંમેશા બે વાર ચાલે તો પણ સલામત બનાવો, નિષ્ફળતાઓ નોંધો, અને જે server સૂઈ શકે કે રીસ્ટાર્ટ થઈ શકે તેની અંદરના timer પર ક્યારેય આધાર ન રાખો.

આ માર્ગદર્શિકા વિકલ્પો સમજાવે છે, દરેક ક્યારે બંધબેસે છે, અને AI app builder સાથે તેમને કેવી રીતે સેટ કરવા, શૂન્ય પર scale થતા હોસ્ટ પર પણ.

background job શું ગણાય

કંઈ પણ જે ધીમું, અવિશ્વસનીય છે, અથવા વપરાશકર્તાના તાત્કાલિક જવાબ માટે જરૂરી નથી:

• ઇમેઇલ, સૂચનાઓ અને રસીદો મોકલવી
• છબીઓનું કદ બદલવું, video transcode કરવો, PDF બનાવવી
• ધીમા third-party APIs ને બોલાવવા, લાંબા કામ માટે AI મોડેલ સહિત
• બીજી સિસ્ટમમાંથી ડેટા import અથવા sync કરવો
• રાત્રિનું clean-up, રિપોર્ટ અને યાદ અપાવવું

આ વિનંતીની અંદર કરવાથી પેજ ધીમા અને નાજુક બને છે: જો ઇમેઇલ provider બંધ હોય, તો વપરાશકર્તાનું sign-up નિષ્ફળ જાય છે. તેને background માં ખસેડવાથી વપરાશકર્તાને તરત જવાબ મળે છે અને job ફરી પ્રયાસ કરી શકાય છે.

વિકલ્પો

કોઈ એક જ સાચો જવાબ નથી. નાની એપને ઘણી વાર ફક્ત database queue અને external scheduler જોઈએ.

શૂન્ય પર scale થતા હોસ્ટ ચિત્ર કેવી રીતે બદલે છે

ઘણા આધુનિક હોસ્ટ, જ્યારે કોઈ એપ વાપરતું ન હોય ત્યારે તેને સૂવડાવે છે અને આગલી વિનંતી પર જગાડે છે. આ પૈસા બચાવે છે, પણ સૂતેલો server કોઈ કોડ ચલાવતો નથી: timers ફાયર થતા નથી અને workers poll કરતા નથી. આ હોસ્ટ પર, scheduled કામ આવતી વિનંતીથી શરૂ થવું જોઈએ, અને તે વિનંતીનો સૌથી સરળ સ્રોત external scheduler છે. દરેક call એપને (અને ઘણી વાર તેના database ને) જગાડે છે, તેથી દર મિનિટે બોલાવવું દર 15 મિનિટે બોલાવવા કરતાં વધુ ખર્ચે છે. જરૂરિયાત પૂરી કરતું સૌથી ધીમું સમયપત્રક પસંદ કરો.

પેટર્ન 1: database job queue

Triggered jobs માટે:

1. jobs table બનાવો: પ્રકાર, payload (JSON), સ્થિતિ (pending, running, done, failed), attempts, run_after, last_error, timestamps.
2. કંઈ થાય ત્યારે, કારણભૂત ફેરફાર સાથે એ જ transaction માં job row insert કરો, જેથી તે સાથે સફળ થાય કે સાથે નિષ્ફળ જાય.
3. worker લાયક jobs ઉપાડે, તેમને running ચિહ્નિત કરે, કામ કરે અને done ચિહ્નિત કરે.
4. નિષ્ફળતા પર, attempts વધારો, run_after પછીનો સેટ કરો (ઉદાહરણ તરીકે 1, 5, પછી 30 મિનિટ) અને ભૂલ સાચવો. મહત્તમ પછી, તેને failed ચિહ્નિત કરો અને કોઈને alert કરો.

જો એક સાથે એક કરતાં વધુ workers ચાલી શકે, તો jobs સુરક્ષિત રીતે claim થવા જોઈએ. Postgres પર, SELECT ... FOR UPDATE SKIP LOCKED દરેક worker ને અલગ rows claim કરવા દે છે, અથડામણ વગર.

worker કોણ ચલાવે? હંમેશા ચાલુ server પર, અલગ process માં એક loop. શૂન્ય-scale હોસ્ટ પર, પેટર્ન 2 માંનો scheduled endpoint દરેક call પર લાયક jobs નો batch પ્રોસેસ કરી શકે.

પેટર્ન 2: તમારી એપને બોલાવતો external scheduler

Scheduled jobs માટે:

1. POST /api/cron/send-reminders જેવો endpoint ઉમેરો.
2. તેને સુરક્ષિત કરો: header માં secret token જરૂરી બનાવો, જે બંને બાજુ secret તરીકે સચવાય, અને બીજું બધું નકારો.
3. તેને idempotent બનાવો: એક જ મિનિટમાં તેને બે વાર ચલાવવાથી બે યાદ અપાવણી ન જવી જોઈએ. શું મોકલાયું તે નોંધો.
4. દરેક call ને ટૂંકો રાખો: એક batch (ધારો કે 100 વસ્તુઓ) પ્રોસેસ કરો અને બાકીનું આગલી call ઉપાડે.
5. scheduler ને તેના પર નિર્દેશિત કરો.

Scheduler ના વિકલ્પો:

• GitHub Actions scheduled workflows. GitHub ની usage મર્યાદામાં મફત. સપ્ટેમ્બર 2026 સુધીમાં, GitHub ના દસ્તાવેજો કહે છે કે સૌથી ટૂંકો અંતરાલ દર 5 મિનિટે એક વાર છે, વ્યસ્ત સમયમાં runs વિલંબિત થઈ શકે (ખાસ કરીને દરેક કલાકની શરૂઆતે), schedules ડિફૉલ્ટ રીતે UTC વાપરે છે, અને જાહેર repository માં scheduled workflows 60 દિવસ repository પ્રવૃત્તિ વગર રહે તો બંધ થાય છે.
• Hosted cron સેવાઓ. ઘણી સેવાઓ છે જેનું એકમાત્ર કામ સમયપત્રક પર URL બોલાવવાનું છે. એક પર આધાર રાખતા પહેલા વિશ્વસનીયતા, ન્યૂનતમ અંતરાલ અને alerting તપાસો.
• તમારા cloud provider નો scheduler. જો તમે પહેલેથી મોટો cloud provider વાપરો છો, તો તેમાં managed scheduler હશે જે HTTPS endpoint ને બોલાવી શકે.
• Hosted job અથવા workflow સેવા. આ scheduling, queues અને retries ભેગા કરે છે, અને દરેક પગલા માટે તમારા endpoints ને બોલાવે છે. દરેક વિક્રેતાની સાઇટ પર કિંમતો અને મર્યાદાઓની તુલના કરો.

પેટર્ન 3: provider ને કામ કરવા દો

કેટલીકવાર શ્રેષ્ઠ background job કોઈ જ નથી:

• પેમેન્ટ. Stripe નિષ્ફળ subscription payments ફરી પ્રયાસ કરે છે અને webhooks મોકલે છે; તમે polling ને બદલે પ્રતિક્રિયા આપો છો. જુઓ webhook શું છે.
• ઇમેઇલ. એકવાર તમે સંદેશ સોંપો, provider ડિલિવરીને queue અને retry કરે છે.
• બલ્ક AI કામ. OpenAI અને Anthropic બિન-તાકીદની વિનંતીઓ માટે batch APIs ઓફર કરે છે, જે તમે સબમિટ કરો અને પછીથી એકત્ર કરો.

તમારા AI builder ને આપવા માટેના prompts

queue માટે:

અમારા database માં jobs table (પ્રકાર, payload JSON, સ્થિતિ, attempts, run_after, last_error) નો ઉપયોગ કરીને background job queue ઉમેરો. જ્યારે વપરાશકર્તા sign up કરે, ત્યારે inline ઇમેઇલ મોકલવાને બદલે એ જ transaction માં send_welcome_email job insert કરો. processJobs(limit) function ઉમેરો જે લાયક jobs ને SELECT ... FOR UPDATE SKIP LOCKED વડે claim કરે, તેમને ચલાવે, અને નિષ્ફળતાઓને 1, 5 અને 30 મિનિટ પછી ફરી પ્રયાસ કરે, 4 પ્રયાસ પછી તેમને failed ચિહ્નિત કરે.

scheduled trigger માટે:

POST /api/cron/tick ઉમેરો, જે CRON_SECRET secret માંથી bearer token વડે સુરક્ષિત હોય; તે વગરની કોઈ પણ વિનંતી નકારો. દરેક call processJobs(100) ચલાવે અને આગામી 24 કલાકમાં લાયક, હજી ન મોકલાયેલી બુકિંગ યાદ અપાવણી મોકલે, મોકલાયેલી યાદ અપાવણીઓ નોંધીને કંઈ બે વાર ન જાય તેની ખાતરી કરે. જે ચાલ્યું તેનો JSON સારાંશ પાછો આપો. પછી એક GitHub Actions workflow લખો જે દર 15 મિનિટે આ endpoint ને બોલાવે, URL અને token repository secrets માંથી વાંચીને.

સામાન્ય ભૂલો

• setInterval પર આધાર રાખવો. server સૂવે કે રીસ્ટાર્ટ થાય ત્યારે તે ચૂપચાપ બંધ થાય છે, અને બે નકલો ચાલે ત્યારે બમણું થાય છે.
• અસુરક્ષિત cron endpoint. જે કોઈ તેને શોધે તે તમારી jobs, અથવા તમારું ઇમેઇલ બિલ, ટ્રિગર કરી શકે.
• Idempotent ન હોય તેવા jobs. retries અને ડુપ્લિકેટ scheduler calls થશે. તેમના માટે ડિઝાઇન કરો.
• નિષ્ફળતા દેખાતી ન હોવી. જે job એક અઠવાડિયું ચૂપચાપ નિષ્ફળ જાય તે મોટેથી નિષ્ફળ જતી job કરતાં ખરાબ છે. ભૂલો લૉગ કરો અને વારંવારની નિષ્ફળતાઓ પર alert કરો.
• એક જ વિનંતીમાં લાંબા રન. વિનંતીઓનો સમય પૂરો થાય છે. batches માં પ્રોસેસ કરો.
• ખૂબ વારંવાર સમયપત્રક. શૂન્ય-scale હોસ્ટ પર દરેક call એપને જગાડે અને બિલ કરે. અંતરાલ વાસ્તવિક જરૂરિયાત સાથે મેળવો.
• સમય ઝોન. "સવારે 9" તમારા scheduler (ઘણી વાર UTC) અને તમારા વપરાશકર્તાઓ માટે જુદો અર્થ ધરાવે છે. સમય UTC માં સાચવો અને દરેક વપરાશકર્તા પ્રમાણે રૂપાંતરિત કરો.
• Workflow ફાઇલમાં secrets. tokens ને scheduler ના secret store માં રાખો. જુઓ API keys કેવી રીતે સુરક્ષિત રાખવી.

ચેકલિસ્ટ

• ધીમું કામ વપરાશકર્તા વિનંતીઓમાંથી બહાર ખસેડાયું
• Jobs ફક્ત memory માં નહીં, ટકાઉ રીતે સચવાયેલા છે
• વધતા વિલંબ અને મહત્તમ સાથે retries
• દરેક job બે વાર ચાલે તો પણ સલામત
• Scheduled endpoint secret token વડે સુરક્ષિત
• દરેક રન એક મર્યાદિત batch પ્રોસેસ કરે છે
• નિષ્ફળ jobs દેખાય છે, alerts સાથે
• હોસ્ટિંગ ખર્ચ ધ્યાનમાં રાખીને schedule અંતરાલ પસંદ કર્યો
• સમય UTC માં સંગ્રહિત છે

Mythex માં background jobs

Mythex ના દસ્તાવેજો scheduled અથવા cron jobs નું વર્ણન કરતા નથી, અને પ્રકાશિત એપ તથા તેમના databases નિષ્ક્રિય હોય ત્યારે સૂઈ જાય છે અને આગલી વિનંતી પર જાગે છે (જુઓ Hosting limits). તેથી તમારી એપની અંદરના timers પર આધાર ન રાખો. જે રસ્તો કામ કરે છે તે ઉપરનો જ છે: એજન્ટને jobs table અને token વડે સુરક્ષિત endpoint માટે કહો, પછી external scheduler ને તમારા પ્રકાશિત URL પર નિર્દેશિત કરો. token ને પ્રોજેક્ટ secret તરીકે સાચવો, અને યાદ રાખો કે દરેક જાગવાથી એપ અને database જાગતા રહે તે સમય માટે credits ખર્ચાય છે, તેથી સમજદાર અંતરાલ પસંદ કરો. જો આ માટે તમારી એપને API backend જોઈએ, તો REST API backend recipe શરૂઆત છે, અને REST API કેવી રીતે બનાવવી endpoints ડિઝાઇન કરવાનું આવરી લે છે. જો હંમેશા ચાલતા workers અથવા bots તમારી પ્રોડક્ટનો મુખ્ય ભાગ હોય, તો સતત પ્રક્રિયાઓ માટે બનાવેલો હોસ્ટ તમને વધુ અનુકૂળ આવી શકે.

પ્રશ્નો