پہلے واضح کریں کہ “صرف ایک node cronjob چلائے” کا مطلب کیا ہے۔ بیک وقت اجرا روکنا اور کاروباری اثر دہرانے سے روکنا الگ ضروریات ہیں۔ مشترک scheduler اجرا مربوط کرتا ہے؛ کام خود crash اور retry کے بعد بھی محفوظ ہونا چاہیے۔
تین NestJS nodes پر روزانہ invoice job سوچیں۔ کام ہونا چاہیے مگر worker restart پر دوسری invoice نہ بنے۔
ہر application instance اپنا cron callback رجسٹر کرتی ہے۔ مقررہ وقت پر ہر ایک الگ شروع ہو سکتی ہے:
00:00 -> Node A -> invoice task
-> Node B -> invoice task
-> Node C -> invoice task
مقامی isRunning flag صرف ایک process میں ہے۔ NestJS waitForCompletion اسی instance میں overlapping callbacks روک سکتا ہے، دوسرے nodes کو مربوط نہیں کرتا۔ تینوں میں یہی flag تین الگ فیصلے ہی رہتا ہے۔ NestJS scheduling۔
اس لیے مشترک جگہ چاہیے جو طے کرے کہ کون سا کام موجود ہے اور کون کر سکتا ہے۔
| صورت | انتخاب | باقی ذمہ داری |
|---|---|---|
| Platform پہلے scheduled jobs دیتا ہے | Scheduling کو web instances سے باہر رکھیں | Overlap، recovery اور missed runs طے کریں۔ |
| ٹیم BullMQ چلاتی ہے | مشترک Job Scheduler اور مخصوص queue | مشترک concurrency اور محفوظ retries طے کریں۔ |
| کام application nodes پر رہنا چاہیے | مشترک lock یا lease | مالک، expiry اور پرانے workers درست سنبھالیں۔ |
Invoice مثال میں Redis اور BullMQ پہلے ہیں تو مستحکم scheduler ID والا مشترک scheduler عملی انتخاب ہے۔ Schedule اور workers الگ کریں تاکہ web nodes بڑھانے سے الگ schedules نہ بنیں۔
Supported BullMQ ورژن میں مخصوص queue کی global concurrency ایک رکھیں۔ یہ تمام workers کے فعال jobs محدود کرتا ہے؛ ہر worker کی local concurrency ایک ہونے سے پھر بھی کئی workers مختلف jobs ساتھ چلا سکتے ہیں۔ Global concurrency۔
طے کریں کہ کل کا کام ابھی چل رہا ہو تو انتظار، چھوڑنا یا occurrences ملانا ہے۔ ٹائم زون اور downtime کے بعد چھوٹی ہوئی کاروباری تاریخیں پوری کرنے کا اصول بنائیں۔
فرض کریں worker invoice بناتا ہے اور completion لکھنے سے پہلے crash ہوتا ہے۔ Recovery job پھر چلا سکتی ہے، حالانکہ invoice موجود ہے۔
[Create invoice] -> [Crash before completion]
|
[Retry]
|
[Same business key: reuse result]
مستحکم business key استعمال کریں، مثلاً customer اور billing period۔ مقامی database میں unique constraint اور transaction invoice کو completed-run record سے جوڑ سکتے ہیں۔ Retry نئی invoice کے بجائے موجودہ نتیجہ پاتا ہے۔
بیرونی provider کی idempotency key استعمال کریں اگر دستیاب ہو، اور غیر یقینی نتائج reconcile کریں۔ Queue job ID یا محفوظ job record اکیلا مستقل ضمانت نہیں کہ کاروباری عمل دوبارہ نہیں ہوگا۔ Idempotent jobs۔
مشترک lock atomically حاصل کریں۔ Ownership token، expiry اور renewal رکھیں؛ token اب بھی ملے تبھی release کریں۔ ورنہ پرانا worker نئے worker کا lock چھوڑ سکتا ہے۔
Expiry ایک اور حالت پیدا کرتی ہے: رکا ہوا worker lease ختم ہونے کے بعد واپس آتا ہے جبکہ نیا worker چل رہا ہے۔ اہم writes کے لیے fencing tokens درکار ہو سکتے ہیں—بڑھتے ownership نمبر جنہیں destination جانچ کر پرانے workers رد کرتا ہے۔ محض لمبا timeout خطرہ نہیں مٹاتا۔
Coordination دستیاب نہ ہو تو طے کریں کہ کام بغیر ownership چلنے کے بجائے انتظار کرے۔ اہم نتائج والے کام میں یہ اکثر محفوظ انتخاب ہے۔
کئی nodes، invoice بننے کے بعد crash، lease سے لمبا pause، Redis رابطہ ٹوٹنا اور rolling deployment ٹیسٹ کریں۔ کاروباری تاریخ، worker، کوشش اور نتیجہ لکھیں تاکہ دہرائی کوشش اور دہرایا اثر الگ پہچانیں۔
یاد رکھیں: scheduling مربوط کریں → مشترک اجرا محدود کریں → business action کو retry-safe بنائیں → recovery آزمائیں۔ “ایک active job” اکیلا بالکل ایک کاروباری اثر کا ثبوت نہیں۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں