EventEmitter اور job queue میں انتخاب کرتے وقت پوچھیں کہ کام کہاں چلنا ہے اور process رک جائے تو کیا ہوگا۔
EventEmitter ایک Node.js process کے اندر listeners کو مطلع کرتا ہے۔ Durable queue کام محفوظ رکھتی ہے تاکہ workers بعد میں کریں۔ دونوں ذمہ داریاں الگ کرتے ہیں مگر failure رویہ مختلف ہے۔
فرض کریں component initialization مکمل کرکے اسی process کے دوسرے components کو ردعمل دینا چاہتا ہے۔ EventEmitter مناسب ہے: listeners رجسٹر کریں، پھر event emit کریں۔
[One process]
emit("ready") -> Listener A
-> Listener B
Node.js listeners کو registration ترتیب میں synchronously بلاتا ہے۔ Event بعد میں رجسٹر ہونے والوں کے لیے محفوظ نہیں ہوتا، اور نامکمل کام process crash سے نہیں بچتا۔ Node.js Events۔
یہ تب درست ہے جب اطلاع مقامی ہو اور کھو یا دوبارہ بن سکے۔ اگر کاروبار چاہتا ہے کہ کام sender کے بعد بھی بچے تو یہ ناکافی ہے۔
Async listener asynchronous کام شروع کر سکتا ہے، مگر emit اس کی واپس کردہ promise کا انتظار نہیں کرتا۔ اس لیے بلانے کی ترتیب تکمیل کی ترتیب لازماً نہیں۔
Listener کا CPU-heavy synchronous code process کو پھر بھی روکتا ہے۔ Thrown errors اور rejected promises سنبھالیں؛ captureRejections ردشدہ promises کو error handling میں بھیج سکتا ہے، مگر task محفوظ یا retry نہیں کرتا۔
Async کام کرنے کا انداز بدلتا ہے۔ In-memory event کو durable queue نہیں بناتا۔
اب فرض کریں order save ہونے کے بعد invoice بننا ضروری ہے۔ Workers مصروف یا دستیاب نہ ہوں تو queue instruction رکھتی ہے۔
[Producer] -> [Durable queue] -> [Available worker]
| |
[Pending work] [Result / retry]
Producer job بھیجتا ہے؛ worker ایک کوشش process کرکے result محفوظ کرتا ہے۔ Workers کو API سے الگ deploy اور scale کر سکتے ہیں۔ Durability queue کے storage اور configuration پر منحصر ہے۔
عام competing-worker queue میں ہر کوشش ایک worker کرتا ہے۔ یہ ہر EventEmitter listener کو event دینے سے مختلف ہے۔ اگر کئی آزاد subscribers میں ہر ایک کو event چاہیے تو موزوں delivery model چنیں یا configure کریں۔
EventEmitter میں order save ہونے کے بعد مگر emit سے پہلے crash invoice instruction کھو سکتا ہے۔ Durable queue قبول کرنے کے بعد job بچاتی ہے، database commit اور submission کے پہلے خلا کو خود نہیں بچاتی۔
Outbox order اور instruction ایک database transaction میں محفوظ کرکے یہ خلا بند کرتا ہے۔ Publisher اسے پڑھ کر job بعد میں بھیجتا ہے۔
Publisher کی confirmation کھو جائے تو delivery دہر سکتی ہے۔ Invoice creation کو stable business key اور unique constraint یا دوسری idempotent implementation دیں۔ دوبارہ کوشش دوسری invoice نہ بنائے۔ Idempotent jobs۔
| ضرورت | EventEmitter | Durable job queue |
|---|---|---|
| ایک process کے components کو اطلاع | براہِ راست اور ہلکا | عموماً غیر ضروری infrastructure بڑھاتی ہے۔ |
| Sender رکنے کے بعد pending کام بچانا | Built-in durable record نہیں | مناسب storage اور recovery سے ممکن۔ |
| Retry اور backlog دیکھنا | Application کو بنانا ہوگا | Configuration کے ساتھ عام queue سہولتیں۔ |
| دوسری machines پر کام | اس کا کردار نہیں | Workers آزاد چل سکتے ہیں۔ |
Initialization کے لیے EventEmitter لوں گا۔ Failure سے بحال ہونے والی invoice generation کے لیے durable queue کے ساتھ database handoff اور duplicate attempts سنبھالوں گا۔
اہم حدود پر process روک کر آزمائیں: submission سے پہلے، قبولیت کے بعد اور business effect کے بعد۔ نتیجہ صارف کی متوقع ضمانت کے مطابق ہونا چاہیے۔
یاد رکھیں: مقامی اطلاع → EventEmitter؛ recoverable background کام → durable queue۔ اہم effects کے لیے handoff اور idempotency بھی ڈیزائن کریں۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں