ویب ایپ میں پس منظر کے jobs کیسے چلائیں: queues، schedulers اور cron

ویب ایپ میں پس منظر کے jobs چلانے کے لیے پہلے کام کو دو قسموں میں تقسیم کریں۔ trigger ہونے والے jobs (خوش آمدیدی ای میل بھیجنا، اپ لوڈ پروسیس کرنا) کو job queue میں محفوظ کیا جا سکتا ہے، جو اکثر آپ کے ڈیٹا بیس کا ایک ٹیبل ہوتا ہے، اور ایک worker انہیں دوبارہ کوشش کے ساتھ سنبھالتا ہے۔ شیڈول شدہ jobs (رات کی رپورٹ، ہر 15 منٹ پر یاددہانیاں) کو کسی ایسی چیز کی ضرورت ہے جو طے شدہ وقت پر چلے: ہوسٹ کی cron سہولت، یا ایک بیرونی scheduler جو آپ کی ایپ کے کسی محفوظ endpoint کو کال کرے۔ jobs کو ہمیشہ دو بار چلانا محفوظ بنائیں، ناکامیوں کا ریکارڈ رکھیں، اور ایسے سرور کے اندر ٹائمر پر کبھی بھروسہ نہ کریں جو سو سکتا ہو یا دوبارہ شروع ہو سکتا ہو۔

یہ گائیڈ اختیارات، ہر ایک کب موزوں ہے، اور AI ایپ بلڈر کے ساتھ انہیں کیسے سیٹ اپ کریں، یہ بتاتی ہے، بشمول ان ہوسٹس پر جو صفر تک سکیل ہوتے ہیں۔

پس منظر کا job کس چیز کو کہتے ہیں

ہر وہ کام جو سست، ناقابلِ اعتماد ہو یا صارف کے فوری جواب کے لیے ضروری نہ ہو:

ای میلز، اطلاعات اور رسیدیں بھیجنا
تصاویر ریسائز کرنا، ویڈیو ٹرانسکوڈ کرنا، PDFs بنانا
سست تھرڈ پارٹی APIs کو کال کرنا، بشمول طویل کاموں کے لیے AI ماڈلز
کسی دوسرے نظام سے ڈیٹا درآمد یا sync کرنا
رات کی صفائی، رپورٹس اور یاددہانیاں

یہ کام درخواست کے اندر کرنے سے صفحات سست اور نازک ہو جاتے ہیں: اگر ای میل فراہم کنندہ بند ہو تو صارف کا سائن اَپ ناکام ہو جاتا ہے۔ اسے پس منظر میں منتقل کرنے سے صارف کو فوری جواب ملتا ہے اور job دوبارہ کوشش کے قابل رہتا ہے۔

اختیارات

اختیار	کیسے کام کرتا ہے	فوائد	نقصانات
اسی پروسیس میں fire-and-forget	جواب دیں، پھر سرور میں کام جاری رکھیں	کوئی سیٹ اپ نہیں	سرور رکنے پر ضائع؛ دوبارہ کوشش نہیں
اندرونی ٹائمر (`setInterval`، `setTimeout`)	چلتے سرور میں ایک ٹائمر	بہت آسان	سوتے وقت نہیں چلتا؛ کئی نسخوں میں دہرا چلتا ہے
ڈیٹا بیس پر مبنی queue	jobs قطاروں کے طور پر محفوظ؛ ایک worker انہیں لے کر چلاتا ہے	وہی ڈیٹا بیس جو آپ کے پاس ہے؛ پائیدار؛ دیکھنا آسان	retries اور locking آپ بناتے ہیں؛ worker چلانے کے لیے کچھ چاہیے
مخصوص queue (Redis پر مبنی یا منظم)	ایک queue سروس اور workers	پختہ retry اور شیڈولنگ کی خصوصیات	ایک اور سروس چلانی اور اس کی ادائیگی کرنی ہے
ہوسٹڈ job یا workflow سروس	ایک تھرڈ پارٹی retries اور شیڈول کے ساتھ آپ کے endpoints کو کال کرتی ہے	شیڈولنگ اور retries آپ کے لیے سنبھالی جاتی ہیں	وینڈر پر انحصار؛ ایک اور اکاؤنٹ اور key
بیرونی scheduler جو endpoint کو کال کرے	کہیں اور کا ٹائمر طے شدہ وقت پر HTTP درخواست بھیجتا ہے	کسی بھی ہوسٹ پر کام کرتا ہے، بشمول صفر تک سکیل	کم از کم وقفے اور تاخیر؛ endpoint کو محفوظ کریں
ہوسٹ کا اپنا cron	پلیٹ فارم طے شدہ وقت پر کمانڈ چلاتا ہے	جہاں موجود ہو وہاں سادہ	ہر ہوسٹ یہ پیش نہیں کرتا

کوئی ایک درست جواب نہیں۔ ایک چھوٹی ایپ کو اکثر صرف ایک ڈیٹا بیس queue اور ایک بیرونی scheduler کی ضرورت ہوتی ہے۔

صفر تک سکیل ہونے والے ہوسٹس تصویر کیوں بدلتے ہیں

بہت سے جدید ہوسٹس آپ کی ایپ کو تب سلا دیتے ہیں جب کوئی اسے استعمال نہ کر رہا ہو اور اگلی درخواست پر جگا دیتے ہیں۔ اس سے پیسے بچتے ہیں، مگر سوتا ہوا سرور کوئی کوڈ نہیں چلاتا: ٹائمرز فائر نہیں ہوتے اور workers پولنگ نہیں کرتے۔ ان ہوسٹس پر شیڈول شدہ کام کو کسی آنے والی درخواست سے شروع ہونا ہوتا ہے، اور اس درخواست کا سب سے آسان ذریعہ بیرونی scheduler ہے۔ ہر کال ایپ کو (اور اکثر اس کے ڈیٹا بیس کو) جگاتی ہے، اس لیے ہر منٹ کال کرنا ہر 15 منٹ کے مقابلے میں زیادہ خرچ کرتا ہے۔ ضرورت پوری کرنے والا سب سے سست شیڈول چنیں۔

پیٹرن 1: ڈیٹا بیس job queue

trigger ہونے والے jobs کے لیے:

ایک jobs ٹیبل بنائیں: قسم، payload (JSON)، حیثیت (pending، running، done، failed)، کوششیں، run_after، last_error، ٹائم اسٹیمپس۔
جب کچھ ہو، تو اسی ٹرانزیکشن میں جس تبدیلی نے اسے شروع کیا ایک job کی قطار داخل کریں، تاکہ وہ ایک ساتھ کامیاب یا ناکام ہوں۔
ایک worker وقت آنے والے jobs اٹھاتا ہے، انہیں running نشان زد کرتا ہے، کام کرتا ہے اور done نشان زد کرتا ہے۔
ناکامی پر attempts بڑھائیں، run_after کو بعد کا وقت دیں (مثلاً 1، 5، پھر 30 منٹ) اور خرابی محفوظ کریں۔ زیادہ سے زیادہ حد کے بعد اسے failed نشان زد کریں اور کسی کو الرٹ کریں۔

اگر ایک سے زیادہ workers ایک ساتھ چل سکتے ہوں تو jobs کو محفوظ طریقے سے حاصل کرنا ہوگا۔ Postgres پر SELECT ... FOR UPDATE SKIP LOCKED ہر worker کو الگ قطاریں بغیر ٹکراؤ کے لینے دیتا ہے۔

worker کو کون چلاتا ہے؟ ہمیشہ چلنے والے سرور پر، ایک الگ پروسیس میں ایک loop۔ صفر تک سکیل ہونے والے ہوسٹ پر، پیٹرن 2 کا شیڈول شدہ endpoint ہر کال پر وقت آنے والے jobs کا ایک بیچ پروسیس کر سکتا ہے۔

پیٹرن 2: بیرونی scheduler جو آپ کی ایپ کو کال کرے

شیڈول شدہ jobs کے لیے:

ایک endpoint شامل کریں، جیسے POST /api/cron/send-reminders۔
اسے محفوظ کریں: ہیڈر میں ایک خفیہ token مانگیں، جو دونوں طرف secret کے طور پر محفوظ ہو، اور باقی سب رد کریں۔
اسے idempotent بنائیں: ایک ہی منٹ میں دو بار چلنے سے دو یاددہانیاں نہیں جانی چاہئیں۔ جو بھیجا گیا وہ ریکارڈ کریں۔
ہر کال کو مختصر رکھیں: ایک بیچ (مثلاً 100 آئٹمز) پروسیس کریں اور باقی اگلی کال پر چھوڑیں۔
ایک scheduler کو اس کی طرف اشارہ کریں۔

scheduler کے انتخاب:

GitHub Actions کے شیڈول شدہ workflows۔ GitHub کی استعمال کی حدوں کے اندر مفت۔ ستمبر 2026 تک، GitHub کی دستاویزات کے مطابق سب سے کم وقفہ ہر 5 منٹ میں ایک بار ہے، مصروف اوقات میں رنز میں تاخیر ہو سکتی ہے (خاص طور پر ہر گھنٹے کے آغاز میں)، شیڈولز بطور ڈیفالٹ UTC استعمال کرتے ہیں، اور عوامی repository میں شیڈول شدہ workflows 60 دن تک repository کی سرگرمی نہ ہونے پر غیر فعال ہو جاتے ہیں۔
ہوسٹڈ cron سروسز۔ بہت سی سروسز ہیں جن کا واحد کام شیڈول پر ایک URL کو کال کرنا ہے۔ کسی پر انحصار کرنے سے پہلے قابلِ اعتمادیت، کم سے کم وقفہ اور الرٹنگ جانچیں۔
آپ کے کلاؤڈ فراہم کنندہ کا scheduler۔ اگر آپ پہلے سے ایک بڑا کلاؤڈ فراہم کنندہ استعمال کرتے ہیں تو اس کے پاس ایک منظم scheduler ہوگا جو HTTPS endpoint کو کال کر سکتا ہے۔
ہوسٹڈ job یا workflow سروس۔ یہ شیڈولنگ، queues اور retries کو یکجا کرتی ہیں اور ہر مرحلے کے لیے آپ کے endpoints کو کال کرتی ہیں۔ قیمت اور حدیں ہر وینڈر کی سائٹ پر موازنہ کریں۔

پیٹرن 3: فراہم کنندہ کو کرنے دیں

بعض اوقات بہترین پس منظر کا job کوئی نہیں ہوتا:

ادائیگیاں۔ Stripe ناکام سبسکرپشن ادائیگیاں دوبارہ کرتا ہے اور webhooks بھیجتا ہے؛ آپ پولنگ کے بجائے ردِ عمل دیتے ہیں۔ دیکھیں webhook کیا ہوتا ہے۔
ای میل۔ ایک بار پیغام دینے کے بعد فراہم کنندگان ترسیل کو قطار میں لگاتے اور دوبارہ کوشش کرتے ہیں۔
بڑے پیمانے پر AI کام۔ OpenAI اور Anthropic غیر فوری درخواستوں کے لیے batch APIs پیش کرتے ہیں جنہیں آپ بعد میں جمع کراتے اور وصول کرتے ہیں۔

اپنے AI بلڈر کو دینے کے prompts

queue کے لیے:

ہمارے ڈیٹا بیس میں ایک jobs ٹیبل استعمال کرتے ہوئے ایک پس منظر job queue شامل کریں (قسم، payload JSON، حیثیت، کوششیں، run_after، last_error)۔ جب کوئی صارف سائن اَپ کرے تو ای میل بھیجنے کے بجائے اسی ٹرانزیکشن میں ایک send_welcome_email job داخل کریں۔ ایک processJobs(limit) فنکشن شامل کریں جو SELECT ... FOR UPDATE SKIP LOCKED سے وقت آنے والے jobs لے، انہیں چلائے، اور ناکامیوں کو 1، 5 اور 30 منٹ بعد دوبارہ کوشش کرے، اور 4 کوششوں کے بعد انہیں failed نشان زد کرے۔

شیڈول شدہ trigger کے لیے:

POST /api/cron/tick شامل کریں جو CRON_SECRET کے خفیہ bearer token سے محفوظ ہو؛ اس کے بغیر کسی بھی درخواست کو رد کریں۔ ہر کال processJobs(100) چلائے اور اگلے 24 گھنٹوں میں آنے والی بکنگ یاددہانیاں بھیجے جو ابھی نہیں بھیجی گئیں، اور بھیجی گئی یاددہانیاں ریکارڈ کرے تاکہ کچھ دو بار نہ جائے۔ چلنے والی چیزوں کا JSON خلاصہ لوٹائیں۔ پھر ایک GitHub Actions workflow لکھیں جو ہر 15 منٹ بعد اس endpoint کو کال کرے، اور URL اور token repository secrets سے پڑھے۔

عام غلطیاں

setInterval پر انحصار۔ سرور سوتے یا دوبارہ شروع ہوتے وقت یہ خاموشی سے رک جاتا ہے، اور دو نسخے چلنے پر دگنا ہو جاتا ہے۔
غیر محفوظ cron endpoint۔ جو بھی اسے ڈھونڈ لے وہ آپ کے jobs، یا آپ کا ای میل بل، چلا سکتا ہے۔
idempotent نہ ہونے والے jobs۔ دوبارہ کوششیں اور دہرے scheduler کالز ہوں گی۔ ان کے لیے ڈیزائن کریں۔
ناکامی کی نظر نہ آنا۔ ایک job جو ایک ہفتے تک خاموشی سے ناکام ہوتا رہے، اس سے بدتر ہے جو زور سے ناکام ہو۔ خرابیاں لاگ کریں اور بار بار کی ناکامی پر الرٹ کریں۔
ایک درخواست میں لمبے رن۔ درخواستیں وقت سے باہر ہو جاتی ہیں۔ بیچوں میں پروسیس کریں۔
بہت بار شیڈول کرنا۔ صفر تک سکیل ہونے والے ہوسٹ پر ہر کال ایپ کو جگاتی اور اس کا بل بناتی ہے۔ وقفے کو اصل ضرورت کے مطابق رکھیں۔
وقت کے زون۔ "صبح 9 بجے" آپ کے scheduler (اکثر UTC) اور آپ کے صارفین کے لیے مختلف مطلب رکھتا ہے۔ وقت UTC میں محفوظ کریں اور ہر صارف کے لیے تبدیل کریں۔
workflow فائل میں خفیہ معلومات۔ tokens کو scheduler کے secret store میں رکھیں۔ دیکھیں API keys کو محفوظ کیسے رکھیں۔

چیک لسٹ

سست کام صارف کی درخواستوں سے باہر منتقل ہو گیا
jobs صرف میموری میں نہیں، پائیدار طور پر محفوظ ہیں
بڑھتے ہوئے وقفوں اور زیادہ سے زیادہ حد کے ساتھ retries
ہر job دو بار چلانا محفوظ ہے
شیڈول شدہ endpoint خفیہ token سے محفوظ ہے
ہر رن ایک محدود بیچ پروسیس کرتا ہے
ناکام jobs نظر آتے ہیں، الرٹس کے ساتھ
ہوسٹنگ کی لاگت کو ذہن میں رکھ کر شیڈول کا وقفہ چنا گیا
اوقات UTC میں محفوظ ہیں

Mythex میں پس منظر کے jobs

Mythex کی دستاویزات شیڈول شدہ یا cron jobs بیان نہیں کرتیں، اور شائع شدہ ایپس اور ان کے ڈیٹا بیسز غیر فعال ہونے پر سو جاتے ہیں اور اگلی درخواست پر جاگ جاتے ہیں (دیکھیں ہوسٹنگ کی حدود)۔ اس لیے اپنی ایپ کے اندر ٹائمرز پر انحصار نہ کریں۔ جو طریقہ کام کرتا ہے وہ وہی ہے جو اوپر بیان ہوا: ایجنٹ سے jobs کا ٹیبل اور token سے محفوظ endpoint مانگیں، پھر ایک بیرونی scheduler کو اپنے شائع شدہ URL کی طرف اشارہ کریں۔ token کو پروجیکٹ کے secret کے طور پر رکھیں، اور یاد رکھیں کہ ہر جاگنے پر ایپ اور ڈیٹا بیس کے جاگنے کے وقت کے لیے کریڈٹس خرچ ہوتے ہیں، اس لیے مناسب وقفہ چنیں۔ اگر آپ کی ایپ کو اس کے لیے API بیک اینڈ درکار ہے تو REST API بیک اینڈ ایک نقطہ آغاز ہے، اور REST API کیسے بنائیں endpoints ڈیزائن کرنے کا طریقہ بتاتی ہے۔ اگر ہمیشہ چلنے والے workers یا bots آپ کی پروڈکٹ کا مرکز ہیں تو مستقل پروسیسز کے لیے بنایا گیا ہوسٹ زیادہ موزوں ہو سکتا ہے۔

سوالات

پس منظر کا job کیا ہے؟

پس منظر کا job وہ کام ہے جو آپ کی ایپ صارف کی اس درخواست سے باہر کرتی ہے جس کا وہ انتظار کر رہا ہے، جیسے ای میلز بھیجنا، تصاویر ریسائز کرنا، رپورٹس بنانا یا ڈیٹا sync کرنا۔ صارف کو فوری جواب ملتا ہے، job الگ چلتا ہے، اور ناکام ہونے پر دوبارہ کوشش کی جا سکتی ہے۔

اگر میرے ہوسٹ پر cron نہیں ہے تو شیڈول شدہ کام کیسے چلاؤں؟

ایک محفوظ endpoint شامل کریں جو کام کرے، پھر ایک بیرونی scheduler سے اسے طے شدہ وقت پر کال کروائیں۔ اختیارات میں GitHub Actions کا شیڈول شدہ workflow، ایک ہوسٹڈ cron سروس، یا آپ کے کلاؤڈ فراہم کنندہ کا scheduler شامل ہیں۔ endpoint کو ایک خفیہ token سے محفوظ کریں۔

کیا شیڈول شدہ jobs کے لیے setInterval یا setTimeout استعمال کر سکتا ہوں؟

صرف چھوٹے، غیر اہم کاموں کے لیے ایک ایسے سرور پر جو ہمیشہ چلتا ہو۔ اگر سرور دوبارہ شروع ہو، صفر تک سکیل ہو یا کئی نسخے چلائے، تو ٹائمرز ضائع ہو جاتے ہیں یا ایک سے زیادہ بار چلتے ہیں۔ شیڈول شدہ کام ڈیٹا بیس میں محفوظ کریں یا اس کے بجائے scheduler استعمال کریں۔

کیا Mythex cron jobs سپورٹ کرتا ہے؟

Mythex کی دستاویزات شیڈول شدہ یا cron jobs بیان نہیں کرتیں، اور شائع شدہ ایپس غیر فعال ہونے پر سو جاتی ہیں۔ قابلِ اعتماد طریقہ یہ ہے کہ ایک بیرونی scheduler آپ کی ایپ کے کسی محفوظ endpoint کو کال کرے، جو ایپ کو جگاتا ہے اور کام چلاتا ہے۔