Paano Magpatakbo ng Background Jobs sa Web App: Queues, Schedulers at Cron

Para magpatakbo ng background jobs sa web app, hatiin muna ang trabaho sa dalawang uri. Na-trigger na jobs (magpadala ng welcome email, iproseso ang upload) ay maaaring itabi sa job queue, kadalasang table sa database mo, at hawakan ng worker na may retries. Naka-iskedyul na jobs (nightly report, paalala kada 15 minuto) ay nangangailangan ng bagay na tumatakbo ayon sa oras: cron feature ng host, o external scheduler na tumatawag sa protektadong endpoint sa app mo. Laging gawing ligtas na tumakbo nang dalawang beses ang jobs, itala ang mga pagkabigo, at huwag umasa sa timer sa loob ng server na maaaring matulog o mag-restart.

Ipinapaliwanag ng gabay na ito ang mga opsyon, kailan bagay ang bawat isa, at kung paano ito i-set up gamit ang AI app builder, kasama na sa mga host na nag-i-scale to zero.

Ano ang itinuturing na background job

Anumang mabagal, hindi maaasahan, o hindi kailangan sa agarang tugon ng user:

• Pagpapadala ng email, notification at resibo
• Pag-resize ng larawan, pag-transcode ng video, paggawa ng PDF
• Pagtawag sa mabagal na third-party API, kasama ang AI models para sa mahahabang gawain
• Pag-import o pag-sync ng data mula sa ibang sistema
• Nightly na paglilinis, report at paalala

Kapag ginawa ito sa loob ng request, bumabagal at nagiging marupok ang mga pahina: kapag down ang email provider, pumapalya ang sign-up ng user. Kapag inilipat sa background, agad na nakakakuha ng tugon ang user at maaaring ulitin ang job.

Ang mga opsyon

Walang iisang tamang sagot. Kadalasang sapat sa maliit na app ang database queue at external scheduler.

Bakit binabago ng mga host na nag-i-scale to zero ang sitwasyon

Maraming modernong host ang nagpapatulog sa app mo kapag walang gumagamit at ginigising ito sa susunod na request. Nakakatipid iyon, pero ang natutulog na server ay hindi nagpapatakbo ng code: hindi tumutunog ang mga timer at hindi nagpo-poll ang mga worker. Sa mga host na ito, kailangang magsimula sa papasok na request ang naka-iskedyul na trabaho, at ang pinakamadaling pinagmumulan ng request na iyon ay external scheduler. Ginigising ng bawat tawag ang app (at kadalasan ang database nito), kaya mas magastos ang tawag kada minuto kaysa kada 15 minuto. Piliin ang pinakamabagal na iskedyul na tumutugon sa pangangailangan.

Pattern 1: database job queue

Para sa na-trigger na jobs:

1. Gumawa ng jobs table: uri, payload (JSON), status (pending, running, done, failed), attempts, run_after, last_error, timestamps.
2. Kapag may nangyari, magpasok ng job row sa parehong transaction ng pagbabagong nagdulot nito, para magtagumpay o pumalya silang magkasama.
3. Kinukuha ng worker ang mga job na dapat nang patakbuhin, minamarkahang running, ginagawa ang trabaho at minamarkahang done.
4. Kapag pumalya, dinadagdagan ang attempts, inilalayo ang run_after (halimbawa 1, 5, pagkatapos 30 minuto) at itinatabi ang error. Pagkatapos ng maximum, markahang failed at magpadala ng alerto sa isang tao.

Kung maaaring may higit sa isang worker na tumakbo nang sabay, dapat ligtas na makuha ang mga job. Sa Postgres, pinapayagan ng SELECT ... FOR UPDATE SKIP LOCKED ang bawat worker na kumuha ng magkakaibang hilera nang hindi nagbabanggaan.

Ano ang nagpapatakbo ng worker? Sa server na laging nakabukas, isang loop sa hiwalay na proseso. Sa scale-to-zero na host, puwedeng iproseso ng naka-iskedyul na endpoint sa Pattern 2 ang isang batch ng nakatakdang jobs sa bawat tawag.

Pattern 2: external scheduler na tumatawag sa app mo

Para sa naka-iskedyul na jobs:

1. Magdagdag ng endpoint gaya ng POST /api/cron/send-reminders.
2. Protektahan ito: humingi ng secret token sa header, nakaimbak bilang secret sa magkabilang panig, at tanggihan ang anumang iba.
3. Gawin itong idempotent: ang pagpapatakbo nito nang dalawang beses sa loob ng parehong minuto ay hindi dapat magpadala ng dalawang paalala. Itala kung ano ang naipadala.
4. Panatilihing maikli ang bawat tawag: magproseso ng batch (halimbawa 100 item) at hayaang kunin ng susunod na tawag ang natitira.
5. Ituro ang scheduler dito.

Mga pagpipilian sa scheduler:

• GitHub Actions scheduled workflows. Libre sa loob ng usage limits ng GitHub. Ayon sa dokumentasyon ng GitHub noong Setyembre 2026, ang pinakamaikling agwat ay minsan kada 5 minuto, maaaring maantala ang mga takbo tuwing abala ang oras (lalo na sa simula ng bawat oras), UTC ang default na time zone ng iskedyul, at ang scheduled workflows sa public repository ay nao-off pagkatapos ng 60 araw na walang aktibidad sa repository.
• Hosted cron services. Maraming serbisyo ang layunin lang ay tumawag ng URL ayon sa iskedyul. Suriin ang reliability, pinakamaikling agwat at alerto bago umasa sa isa.
• Scheduler ng cloud provider mo. Kung gumagamit ka na ng malaking cloud provider, mayroon itong managed scheduler na makakatawag sa HTTPS endpoint.
• Hosted job o workflow service. Pinagsasama ng mga ito ang scheduling, queues at retries, at tinatawag ang mga endpoint mo para sa bawat hakbang. Ikumpara ang presyo at limitasyon sa site ng bawat vendor.

Pattern 3: hayaang gawin ng provider

Minsan ang pinakamainam na background job ay wala:

• Mga bayad. Muling sinusubukan ng Stripe ang mga pumalyang subscription payment at nagpapadala ng webhooks; ikaw ang tutugon sa halip na mag-poll. Tingnan ang ano ang webhook.
• Email. Pumipila at muling sinusubukan ng mga provider ang paghahatid kapag naibigay mo na ang mensahe.
• Bulk na AI work. Nag-aalok ang OpenAI at Anthropic ng batch APIs para sa hindi madaliang request na isusumite mo at kukunin pagkatapos.

Mga prompt na ibibigay sa AI builder mo

Para sa queue:

Magdagdag ng background job queue gamit ang jobs table sa database natin (uri, payload na JSON, status, attempts, run_after, last_error). Kapag nag-sign up ang user, magpasok ng job na send_welcome_email sa parehong transaction sa halip na magpadala nang inline. Magdagdag ng function na processJobs(limit) na kumukuha ng mga nakatakdang job gamit ang SELECT ... FOR UPDATE SKIP LOCKED, pinapatakbo ang mga ito, at inuulit ang mga pumalya pagkatapos ng 1, 5 at 30 minuto, at minamarkahang failed pagkatapos ng 4 na attempt.

Para sa naka-iskedyul na trigger:

Magdagdag ng POST /api/cron/tick na protektado ng bearer token mula sa secret na CRON_SECRET; tanggihan ang anumang request na wala nito. Bawat tawag ay nagpapatakbo ng processJobs(100) at nagpapadala ng booking reminders na nakatakda sa susunod na 24 na oras at hindi pa naipapadala, itinatala ang mga naipadalang paalala para walang maipadalang dalawang beses. Ibalik ang JSON na buod ng naganap. Pagkatapos, sumulat ng GitHub Actions workflow na tumatawag sa endpoint na ito kada 15 minuto, binabasa ang URL at token mula sa repository secrets.

Mga karaniwang pagkakamali

• Pag-asa sa setInterval. Tahimik itong humihinto kapag natulog o nag-restart ang server, at nagdodoble kapag may dalawang kopyang tumatakbo.
• Hindi protektadong cron endpoint. Sinumang makakita nito ay maaaring magpatakbo ng jobs mo, o magpataas ng email bill mo.
• Mga job na hindi idempotent. Mangyayari ang retries at dobleng tawag ng scheduler. Idisenyo para dito.
• Walang kakayahang makita ang pagkabigo. Ang job na tahimik na pumapalya sa loob ng isang linggo ay mas masama kaysa sa job na malakas pumalya. Mag-log ng error at mag-alerto sa paulit-ulit na pagkabigo.
• Mahahabang takbo sa iisang request. Nagta-timeout ang mga request. Magproseso sa mga batch.
• Sobrang dalas ng iskedyul. Ang bawat tawag sa scale-to-zero na host ay gumigising at naniningil sa app. Itugma ang agwat sa totoong pangangailangan.
• Time zone. Ang "9am" ay magkaibang bagay para sa scheduler mo (kadalasan UTC) at sa mga user mo. Itabi ang oras sa UTC at i-convert kada user.
• Secrets sa workflow file. Itago ang tokens sa secret store ng scheduler. Tingnan ang paano panatilihing ligtas ang API keys.

Checklist

• Nailipat sa labas ng user requests ang mabagal na trabaho
• Matibay na nakaimbak ang jobs, hindi lang sa memorya
• May retries na may tumataas na pagitan at maximum
• Ligtas patakbuhin nang dalawang beses ang bawat job
• Protektado ng secret token ang naka-iskedyul na endpoint
• Bawat takbo ay nagpoproseso ng may hangganang batch
• Nakikita ang mga pumalyang job, may mga alerto
• Pinili ang agwat ng iskedyul na isinasaalang-alang ang gastos sa hosting
• Nakaimbak sa UTC ang mga oras

Background jobs sa Mythex

Hindi inilalarawan ng dokumentasyon ng Mythex ang scheduled o cron jobs, at natutulog ang published apps at kanilang database kapag idle at gumigising sa susunod na request (tingnan ang Hosting limits). Kaya huwag umasa sa mga timer sa loob ng app mo. Ang paraang gumagana ay ang nasa itaas: hilingin sa agent ang jobs table at endpoint na protektado ng token, pagkatapos ituro ang external scheduler sa published URL mo. Itabi ang token bilang project secret, at tandaang bawat paggising ay gumagastos ng credits para sa oras na gising ang app at database, kaya pumili ng makatwirang agwat. Kung kailangan ng app mo ng API backend para dito, magandang panimula ang REST API backend recipe, at sakop ng paano gumawa ng REST API ang pagdidisenyo ng mga endpoint. Kung ang always-on na worker o bot ang pangunahing produkto mo, maaaring mas bagay ang host na ginawa para sa persistent na proseso.

Mga tanong