Web app မှာ background job များ ဘယ်လို run မလဲ: Queue၊ Scheduler နဲ့ Cron

Web app မှာ background job များ run ဖို့ ဦးစွာ အလုပ်ကို နှစ်မျိုး ခွဲပါ။ Triggered job များ (welcome email ပို့ခြင်း၊ upload လုပ်ခြင်း) ကို job queue မှာ သိမ်းနိုင်ပါတယ်၊ ပုံမှန်အားဖြင့် database ထဲက table ဖြစ်ပြီး retry ပါတဲ့ worker က လုပ်ပေးပါတယ်။ Scheduled job များ (နေ့စဉ် report၊ မိနစ် 15 တိုင်း သတိပေးချက်) ကတော့ အချိန်ဇယားအတိုင်း မီးစနိုးတဲ့ အရာ လိုပါတယ်: host ရဲ့ cron feature ဒါမှမဟုတ် app ထဲက ကာကွယ်ထားတဲ့ endpoint ကို ခေါ်တဲ့ external scheduler။ Job တွေကို နှစ်ကြိမ် run လည်း ဘေးကင်းအောင် လုပ်ပါ၊ ပျက်ကွက်မှုတွေ မှတ်ပါ၊ အိပ်နိုင်တဲ့ သို့မဟုတ် ပြန်စတတ်တဲ့ server ထဲက timer ကို ဘယ်တော့မှ မမှီခိုပါနဲ့။

ဒီလမ်းညွှန်က ရွေးချယ်စရာတွေ၊ ဘယ်အခါ ကိုက်ညီလဲ၊ ပြီးတော့ AI app builder နဲ့ ဘယ်လို သတ်မှတ်လဲ — scale to zero လုပ်တဲ့ host တွေပေါ်မှာပါ — ရှင်းပြပါတယ်။

Background job ဆိုတာ ဘာတွေလဲ

အရမ်းနှေး၊ မယုံကြည်ရတဲ့ သို့မဟုတ် user ရဲ့ ချက်ချင်း တုံ့ပြန်မှု မလိုတဲ့ အရာတိုင်း:

• Email၊ notification နဲ့ receipt များ ပို့ခြင်း
• ပုံ resize လုပ်ခြင်း၊ video transcode လုပ်ခြင်း၊ PDF ထုတ်ခြင်း
• နှေးတဲ့ တတိယ ပါတီ API များ ခေါ်ခြင်း၊ ကြာရှည် အလုပ်အတွက် AI model များအပါအဝင်
• တခြား system ကနေ data import/sync လုပ်ခြင်း
• နေ့စဉ် ရှင်းလင်းခြင်း၊ report နဲ့ သတိပေးချက်များ

ဒါကို request ထဲမှာ လုပ်ရင် စာမျက်နှာတွေ နှေးပြီး ပျက်လွယ်ပါတယ်: email ပို့ဝန်ဆောင်မှုပျက်နေရင် user ရဲ့ signup ပျက်သွားပါလိမ့်မယ်။ Background ကို ရွှေ့ရင် user က ချက်ချင်း တုံ့ပြန်မှု ရပြီး job ကို ထပ်ကြိုးစားနိုင်ပါတယ်။

ရွေးချယ်စရာများ

တစ်ခည်းတည်း မှန်ကန်တဲ့ အဖြေ မရှိပါဘူး။ Small app တစ်ခုအတွက် database queue နဲ့ external scheduler တစ်ခု ဆိုရင် လုံလောက်တတ်ပါတယ်။

Scale to zero host တွေက ပုံစံကို ဘယ်လို ပြောင်းလဲစေလဲ

ခေတ်မီ host အများအပြားက ဘယ်သူမှ မသုံးတဲ့အခါ app ကို အိပ်စေပြီး နောက် request မှာ နိုးပေးပါတယ်။ ဒါက ငွေချွေတာပေးပေမဲ့ အိပ်နေတဲ့ server က code ဘာမှ run မပါဘူး: timer တွေ မမီးဖွင့်၊ worker တွေ poll မလုပ်ပါ။ ဒီ host တွေပေါ်မှာ scheduled အလုပ်ဟာ ဝင်လာတဲ့ request နဲ့ စရမယ်၊ ဒါကို လွယ်ဆုံး ရအောင်ပေးတာက external scheduler ပါ။ ခေါ်တိုင်း app (နဲ့ မကြာခဏ database) ကို နှိုးပါတယ်၊ ဒါကြောင့် မိနစ်တိုင်း ခေါ်တာက မိနစ် 15 တိုင်းထက် ပိုကုန်ပါတယ်။ လိုအပ်ချက်ကို ဖြည့်ပေးနိုင်တဲ့ အနှေးဆုံး အချိန်ဇယားကို ရွေးပါ။

Pattern 1: Database job queue

Triggered job များအတွက်:

1. jobs table တစ်ခု ဖန်တီးပါ: type၊ payload (JSON)၊ status (pending၊ running၊ done၊ failed)၊ attempts၊ run_after၊ last_error၊ timestamp များ။
2. တစ်ခုခု ဖြစ်တဲ့အခါ၊ ပြောင်းလဲမှုနဲ့ တူတူ transaction ထဲမှာ job row ကို insert လုပ်ပါ၊ ဒါမှ အတူတူ အောင်မြင်ရင်လည်း အောင်မြင်၊ ကျရင်လည်း ကျပါလိမ့်မယ်။
3. Worker က ခေါ်ဖို့ရနေတဲ့ job တွေကို ယူပြီး running လို့ မှတ်၊ အလုပ်လုပ်ပြီး done လို့ မှတ်ပါ။
4. ပျက်ကွက်ရင် attempts ကို တိုးပြီး run_after ကို နောက်ကျအောင် (ဥပမာ 1၊ 5၊ ထို့နောက် 30 မိနစ်) သတ်မှတ်ပြီး error ကို သိမ်းပါ။ အများဆုံးရောက်ရင် failed လို့ မှတ်ပြီး တစ်စုံတစ်ယောက်ကို သတိပေးပါ။

Worker တစ်ခုထက်ပို run နိုင်ရင် job တွေကို ဘေးကင်းစွာ ယူရပါမယ်။ Postgres မှာဆိုရင် SELECT ... FOR UPDATE SKIP LOCKED က worker တစ်ခုစီကို မတူညီတဲ့ row တွေ ယူခွင့်ပေးပြီး တိုက်မိမှု မရှိပါဘူး။

Worker ကို ဘာက run မလဲ? အမြဲ run နေတဲ့ server ပေါ်မှာဆိုရင် သီးခြား process ထဲက loop။ Scale-to-zero host ပေါ်မှာဆိုရင် Pattern 2 က scheduled endpoint က ခေါ်တိုင်း due job အစုကို process လုပ်နိုင်ပါတယ်။

Pattern 2: External scheduler က သင့် app ကို ခေါ်ခြင်း

Scheduled job များအတွက်:

1. POST /api/cron/send-reminders လို endpoint တစ်ခု ထည့်ပါ။
2. ကာကွယ်ပါ: header ထဲမှာ secret token ကို တောင်းဆိုပြီး နှစ်ဘက်လုံးမှာ secret အနေနဲ့ သိမ်းထားပါ၊ ကျန်တာအားလုံး ပယ်ချပါ။
3. Idempotent လုပ်ပါ: တူတဲ့ မိနစ်တစ်ခုအတွင်း နှစ်ကြိမ် run ရင် သတိပေးချက် နှစ်ခု မပို့ရပါ။ ပို့ပြီးတာကို မှတ်ထားပါ။
4. Call တစ်ခုစီကို တိုတိုလေး ထားပါ: batch တစ်ခု (ဥပမာ 100 ခု) process လုပ်ပြီး ကျန်တာကို နောက် call က ယူပါစေ။
5. Scheduler ကို ဒီ endpoint ဆီ ညွှန်ပါ။

Scheduler ရွေးချယ်စရာများ:

• GitHub Actions scheduled workflow များ။ GitHub ရဲ့ အသုံးပြုမှု ကန့်သတ်ချက်အတွင်း အခမဲ့။ စက်တင်ဘာ 2026 အထိ GitHub ရဲ့ docs အရ အတိုဆုံး interval က မိနစ် 5 တိုင်း တစ်ကြိမ်ဖြစ်ပြီး၊ အလုပ်ရှုပ်တဲ့အချိန် (အထူးသဖြင့် နာရီအစ) မှာ run တွေ နှောင့်နှေးနိုင်ပြီး၊ schedule တွေက default အနေနဲ့ UTC သုံးပြီး၊ public repository ထဲက scheduled workflow တွေက repository activity မရှိတဲ့ ရက် 60 ကြာရင် ပိတ်သွားပါတယ်။
• Hosted cron service များ။ သူ့ရဲ့ တစ်ခုတည်းသော အလုပ်က URL ကို အချိန်ဇယားအတိုင်း ခေါ်တာဖြစ်တဲ့ service များ အများကြီး ရှိပါတယ်။ မှီခိုခင် ယုံကြည်ရမှု၊ အနိမ့်ဆုံး interval နဲ့ alerting ကို စစ်ပါ။
• သင့် cloud provider ရဲ့ scheduler။ Large cloud provider ကို ရှိပြီးသားဆိုရင် HTTPS endpoint ကို ခေါ်နိုင်တဲ့ managed scheduler ရှိပါလိမ့်မယ်။
• Hosted job သို့မဟုတ် workflow service။ Scheduling၊ queue နဲ့ retry ကို ပေါင်းထားပြီး step တစ်ခုချင်းစီအတွက် သင့် endpoint များကို ခေါ်ပါတယ်။ Pricing နဲ့ limit များကို vendor တစ်ခုချင်းစီရဲ့ site မှာ နှိုင်းယှဉ်ပါ။

Pattern 3: Provider ကိုယ်တိုင် လုပ်ခိုင်းပါ

တစ်ခါတစ်လေ အကောင်းဆုံး background job က ဘာမှ မလုပ်ရတာ ဖြစ်ပါတယ်:

• ငွေပေးချေမှု။ Stripe က subscription ငွေပေးချေမှု ကျရှုံးရင် ပြန်ကြိုးစားပြီး webhook ပို့ပေးပါတယ်; သင်က poll မလုပ်ဘဲ တုံ့ပြန်ရုံပါ။ what a webhook is ကို ကြည့်ပါ။
• Email။ Provider တွေက message ကို ပို့ပြီးနောက် delivery ကို queue လုပ်ပြီး retry လုပ်ပေးပါတယ်။
• အစုလိုက် AI အလုပ်။ OpenAI နဲ့ Anthropic က အမြန်မလိုတဲ့ request တွေအတွက် batch API များ ပေးထားပါတယ်၊ သင်က တင်ပြီး နောက်မှ ပြန်ယူနိုင်ပါတယ်။

သင့် AI builder ကို ပေးရမဲ့ prompt များ

Queue အတွက်:

Database ထဲက jobs table (type၊ payload JSON၊ status၊ attempts၊ run_after၊ last_error) ကို သုံးပြီး background job queue ထည့်ပါ။ User signup လုပ်တဲ့အခါ inline ပို့မယ့်အစား တူတူ transaction ထဲမှာ send_welcome_email job ကို insert လုပ်ပါ။ processJobs(limit) function ထည့်ပါ၊ ဒါက due job တွေကို SELECT ... FOR UPDATE SKIP LOCKED နဲ့ ယူပြီး run ကာ ပျက်ရင် 1၊ 5 နဲ့ 30 မိနစ်အကြာ retry လုပ်ပြီး 4 ကြိမ်ကြာရင် failed လို့ မှတ်ပါ။

Scheduled trigger အတွက်:

POST /api/cron/tick ကို CRON_SECRET secret က bearer token နဲ့ ကာကွယ်ပါ; token မပါတဲ့ request ဘာမဆို ပယ်ချပါ။ ခေါ်တိုင်း processJobs(100) run ပြီး နောက် 24 နာရီအတွင်း ရောက်မယ့် booking reminder တွေထဲက မပို့ရသေးတာကို ပို့ပါ၊ ပို့ပြီးတာကို မှတ်ထားပြီး ထပ်မပို့အောင်လုပ်ပါ။ Run ခဲ့တာကို JSON summary နဲ့ ပြန်ပေးပါ။ ပြီးရင် ဒီ endpoint ကို ၁၅ မိနစ်တိုင်း ခေါ်တဲ့ GitHub Actions workflow ရေးပါ၊ URL နဲ့ token ကို repository secret ကနေ ဖတ်ပါ။

အများဆုံး ဖြစ်တတ်တဲ့ အမှားများ

• setInterval ကို မှီခိုခြင်း။ Server အိပ်တာ ဒါမှမဟုတ် ပြန်စတာနဲ့ တိတ်ဆိတ်စွာ ရပ်သွားပြီး မိတ္တူနှစ်ခု run ရင် နှစ်ဆဖြစ်ပါတယ်။
• ကာကွယ်မထားတဲ့ cron endpoint။ ရှာတွေ့သူတိုင်း သင့် job တွေ ဒါမှမဟုတ် email ဘီလ်ကို အစပျိုးနိုင်ပါတယ်။
• Idempotent မဟုတ်တဲ့ job များ။ Retry နဲ့ scheduler call ပွားမှုတွေ ဖြစ်မှာပါ။ အဲဒါအတွက် ဒီဇိုင်းလုပ်ပါ။
• ပျက်ကွက်မှု မမြင်ရခြင်း။ တစ်ပတ်လုံး တိတ်ဆိတ်စွာ ပျက်နေတဲ့ job က ဆူဆူညံညံ ပျက်တဲ့ job ထက် ဆိုးပါတယ်။ Error တွေကို log လုပ်ပြီး ထပ်ခါထပ်ခါ ပျက်ရင် alert ပေးပါ။
• Request တစ်ခုတည်းမှာ run ကြာရှည်ခြင်း။ Request တွေ timeout ဖြစ်ပါတယ်။ Batch နဲ့ process လုပ်ပါ။
• အလွန်ကြာကြာ schedule လုပ်ခြင်း။ Scale-to-zero host ပေါ်က call တိုင်းက app ကို နိုးပြီး ဘီလ်ထုတ်ပါတယ်။ Interval ကို တကယ်လိုအပ်ချက်နဲ့ ကိုက်အောင် ညှိပါ။
• Time zone။ "မနက် 9 နာရီ" က သင့် scheduler (မကြာခဏ UTC) နဲ့ user တွေအတွက် မတူပါ။ အချိန်ကို UTC နဲ့ သိမ်းပြီး user တစ်ယောက်စီအလိုက် ပြောင်းပါ။
• Workflow file ထဲက secret။ Token တွေကို scheduler ရဲ့ secret store မှာ ထားပါ။ how to keep API keys safe ကို ကြည့်ပါ။

စစ်ဆေးစာရင်း

• နှေးတဲ့ အလုပ်တွေကို user request ထဲကနေ ရွှေ့ထားပြီးပါပြီ
• Job တွေကို memory ထဲမှာသာ မဟုတ်ဘဲ ခိုင်ခိုင်မာမာ သိမ်းထားပါတယ်
• Retry တွေမှာ နောက်ကျလာတဲ့ delay နဲ့ အများဆုံး ကန့်သတ်ချက် ရှိပါတယ်
• Job တိုင်း နှစ်ကြိမ် run ရင် ဘေးကင်းပါတယ်
• Scheduled endpoint ကို secret token နဲ့ ကာကွယ်ထားပါတယ်
• Run တစ်ခုစီက batch ကန့်သတ်ထားတဲ့ အရွယ်ကို process လုပ်ပါတယ်
• ပျက်ကွက်တဲ့ job တွေ မြင်ရပြီး alert ရှိပါတယ်
• Schedule interval ကို hosting ကုန်ကျစရိတ်ကို ထည့်စဉ်းစားပြီး ရွေးထားပါတယ်
• အချိန်တွေကို UTC နဲ့ သိမ်းထားပါတယ်

Mythex မှာ background job များ

Mythex ရဲ့ documentation မှာ scheduled သို့မဟုတ် cron job ကို မဖော်ပြထားပါဘူး၊ publish လုပ်ထားတဲ့ app နဲ့ database တွေက အလုပ်မလုပ်တဲ့အခါ အိပ်ပြီး နောက် request မှာ နိုးပါတယ် (Hosting limits ကို ကြည့်ပါ)။ ဒါကြောင့် app ထဲက timer တွေကို မမှီခိုပါနဲ့။ အလုပ်ဖြစ်တဲ့ နည်းလမ်းက အပေါ်က ဖော်ပြထားတာပါပဲ: agent ကို jobs table နဲ့ token နဲ့ ကာကွယ်ထားတဲ့ endpoint ထည့်ခိုင်းပြီး၊ ပြင်ပ scheduler ကို publish လုပ်ထားတဲ့ URL ဆီ ညွှန်ပါ။ Token ကို project secret အဖြစ် သိမ်းပါ၊ နိုးတိုင်း app နဲ့ database နိုးနေတဲ့ အချိန်အတွက် credit ကုန်ကြောင်း မှတ်ထားပြီး သင့်တော်တဲ့ interval ကို ရွေးပါ။ သင့် app ကို ဒါအတွက် API backend လိုအပ်ရင် REST API backend recipe က စတင်ရာ ဖြစ်ပြီး how to build a REST API က endpoint တွေ ဒီဇိုင်းလုပ်ပုံ ရှင်းပြပါတယ်။ Always-on worker သို့မဟုတ် bot တွေက သင့် product ရဲ့ အဓိကဖြစ်ရင် persistent process အတွက် ဆောက်ထားတဲ့ host က ပိုသင့်တော်နိုင်ပါတယ်။

မေးခွန်းများ