EventEmitter ও job queue-এর মধ্যে বাছতে জিজ্ঞেস করুন কাজ কোথায় চলতে হবে এবং process থামলে কী হবে।
EventEmitter একটি Node.js process-এর মধ্যে listener-কে জানায়। Durable queue worker-এর পরবর্তী processing-এর জন্য কাজ রাখে। দুটোই দায়িত্ব আলাদা করে, কিন্তু failure-এর আচরণ ভিন্ন।
ধরুন একটি component initialization শেষ করে একই process-এর অন্য component-কে প্রতিক্রিয়া জানাতে চায়। EventEmitter স্বাভাবিক পছন্দ: listener register করুন, তারপর event emit করুন।
[One process]
emit("ready") -> Listener A
-> Listener B
Node.js নিবন্ধিত listener-কে registration order-এ synchronously ডাকে। পরে register করা listener-এর জন্য event নিজে জমা থাকে না, আর অসমাপ্ত কাজ process crash-এর পর টেকে না। Node.js Events।
Notification local এবং হারিয়ে গেলে বা পুনর্গঠন করলে চললে এটি কাজ করে। Sender থামার পরও কাজ বাঁচতে হবে এমন ব্যবসায়িক প্রত্যাশায় এটি যথেষ্ট নয়।
Async listener asynchronous কাজ শুরু করতে পারে, কিন্তু emit তার returned promise-এর জন্য অপেক্ষা করে না। তাই invocation order ও completion order এক নাও হতে পারে।
সেই listener-এর মধ্যে CPU-heavy synchronous code এখনও process দেরি করায়। Thrown error ও rejected promise ইচ্ছাকৃতভাবে handle করুন; captureRejections rejection error handling-এ পাঠাতে পারে, কিন্তু task persist বা retry করে না।
Async যোগ করলে listener কীভাবে কাজ করে তা বদলায়। Memory-র event durable queue হয়ে যায় না।
এবার ধরুন order save হলে শেষ পর্যন্ত invoice তৈরি হতেই হবে। Worker unavailable বা ব্যস্ত থাকলে queue নির্দেশ ধরে রাখার জায়গা দেয়।
[Producer] -> [Durable queue] -> [Available worker]
| |
[Pending work] [Result / retry]
Producer job পাঠায়; worker একটি attempt process করে ফল লেখে। Worker API থেকে আলাদাভাবে deploy ও scale করা যায়। Durability এখনও queue-র storage ও configuration-এর ওপর নির্ভর করে।
সাধারণ competing-worker queue-তে প্রতি attempt একজন worker করে। এটি সব EventEmitter listener-এ event broadcast করার থেকে আলাদা। একাধিক independent subscriber-এর প্রত্যেকের event লাগলে সেই চাহিদার উপযুক্ত delivery model বাছুন বা configure করুন।
EventEmitter-এ order save-এর পর কিন্তু emit-এর আগে crash হলে invoice নির্দেশ হারাতে পারে। Durable queue job গ্রহণের পর রক্ষা করে, কিন্তু database commit ও submission-এর আগের ফাঁক নিজে রক্ষা করে না।
Outbox order ও নির্দেশ একই database transaction-এ রেখে সেই ফাঁক বন্ধ করে। Publisher outbox পড়ে পরে job পাঠায়।
Publisher confirmation হারালে delivery পুনরাবৃত্ত হতে পারে। Invoice creation-এ stable business key এবং uniqueness constraint বা অন্য idempotent implementation দিন। Attempt আবার হলে দ্বিতীয় invoice হওয়া উচিত নয়। Idempotent jobs।
| চাহিদা | EventEmitter | Durable job queue |
|---|---|---|
| এক process-এর component-কে জানানো | সরাসরি ও হালকা | সাধারণত অপ্রয়োজনীয় infrastructure যোগ করে। |
| Sender থামার পর pending work রাখা | Built-in durable record নেই | উপযুক্ত storage ও recovery-তে সম্ভব। |
| Retry ও backlog দেখা | Application-কে বানাতে হবে | Configuration-সহ প্রচলিত queue ক্ষমতা। |
| অন্য machine-এ কাজ চালানো | এর ভূমিকা নয় | Worker স্বাধীনভাবে চলতে পারে। |
Initialization উদাহরণে আমি EventEmitter নেব। Failure থেকে ফিরতে হবে এমন invoice generation-এ durable queue নেব এবং database handoff ও duplicate attempt সামলাব।
গুরুত্বপূর্ণ boundary-তে process থামিয়ে পরীক্ষা করুন: submission-এর আগে, acceptance-এর পর এবং business effect-এর পর। ফল ব্যবহারকারীর প্রত্যাশিত guarantee-এর সঙ্গে মিলতে হবে।
মনে রাখুন: local notification → EventEmitter; recoverable background work → durable queue। গুরুত্বপূর্ণ effect-এর জন্য handoff ও idempotency-ও design করুন।
বিস্তারিত উত্তরসহ IT ইন্টারভিউ প্রশ্নের একটি লাইব্রেরি — জুনিয়র থেকে সিনিয়র পর্যন্ত।
দান করুন