Node.js में EventEmitter और job queue में क्या अंतर है?

Question

IT Interview Practice · Accepted Answer

EventEmitter और job queue के बीच चुनने के लिए पूछें कि **काम कहां चलना चाहिए और process बंद हो तो क्या होना चाहिए**।

EventEmitter एक Node.js process के listeners को बताता है। Durable queue workers के बाद में process करने के लिए काम रखती है। दोनों जिम्मेदारियां अलग करते हैं, लेकिन failure behavior अलग है।

## 1. Local notification का रास्ता देखें

मान लें component का initialization पूरा हो और उसी process के दूसरे components को प्रतिक्रिया देनी हो। EventEmitter स्वाभाविक विकल्प है: listeners register करें, फिर event emit करें।

```text
[One process]
emit("ready") -> Listener A
              -> Listener B
```

Node.js registered listeners को registration order में synchronously बुलाता है। बाद में register होने वालों के लिए event बचता नहीं और अधूरा काम process crash के बाद नहीं रहता। [Node.js Events](https://nodejs.org/api/events.html)।

Notification local हो और खोने या दोबारा बनाने की गुंजाइश हो तो यह ठीक है। Business चाहता हो कि sender के बंद होने पर भी काम बचे, तो यह पर्याप्त नहीं।

## 2. समझें कि async listener क्या बदलता है

Async listener asynchronous काम शुरू कर सकता है, लेकिन emit उसके returned promise का इंतजार नहीं करता। इसलिए invocation order जरूरी नहीं कि completion order हो।

Listener का CPU-heavy synchronous code अब भी process रोकता है। Thrown errors और rejected promises संभालें; captureRejections उन्हें error handling तक भेज सकता है, लेकिन task को persist या retry नहीं करता।

Async जोड़ने से listener के काम करने का तरीका बदलता है। Memory के event को durable queue नहीं बनाता।

## 3. Queued task का रास्ता देखें

अब मान लें order बचाने के बाद अंततः invoice बनना जरूरी है। Workers उपलब्ध न हों या व्यस्त हों तो queue निर्देश रखने की जगह देती है।

```text
[Producer] -> [Durable queue] -> [Available worker]
                    |                   |
              [Pending work]      [Result / retry]
```

Producer job भेजता है; worker attempt process करके result दर्ज करता है। Workers को API से अलग deploy और scale कर सकते हैं। Durability फिर भी queue के storage और configuration पर निर्भर है।

सामान्य competing-worker queue में हर attempt एक worker संभालता है। यह हर EventEmitter listener को event broadcast करने से अलग है। कई independent subscribers को event चाहिए तो उस जरूरत का delivery model चुनें या configure करें।

## 4. Save और enqueue का अंतर जांचें

EventEmitter में order बचने के बाद emit से पहले crash हो तो invoice instruction खो सकता है। Durable queue acceptance के बाद job बचाती है, लेकिन database commit और submission के बीच का पहले वाला अंतर अपने-आप नहीं बचाती।

Outbox order और निर्देश उसी database transaction में रखकर अंतर बंद करता है। Publisher उसे पढ़कर job बाद में भेजता है।

Publisher confirmation खो दे तो delivery दोहर सकती है। Invoice creation को stable business key और uniqueness constraint या दूसरी idempotent implementation दें। Attempt दोहरने से दूसरा invoice नहीं बनना चाहिए। [Idempotent jobs](https://docs.bullmq.io/patterns/idempotent-jobs)।

## 5. असली जरूरत के आधार पर तुलना करें

| जरूरत | EventEmitter | Durable job queue |
| --- | --- | --- |
| एक process के components को बताना | सीधा और हल्का | सामान्यतः गैरजरूरी infrastructure जोड़ती है। |
| Sender बंद होने पर pending work बचाना | Built-in durable record नहीं | सही storage और recovery के साथ संभव। |
| Retry और backlog देखना | Application को बनाना होगा | सामान्य queue सुविधाएं, configuration के साथ। |
| दूसरी machines पर काम चलाना | यह उसकी भूमिका नहीं | Workers स्वतंत्र चल सकते हैं। |

Initialization के लिए मैं EventEmitter लूंगा। Failure से recover होने वाले invoice generation के लिए durable queue लूंगा और database handoff तथा duplicate attempts संभालूंगा।

महत्वपूर्ण सीमाओं पर process रोककर जांचें: submission से पहले, acceptance के बाद और business effect के बाद। Result user की अपेक्षित guarantee से मेल खाना चाहिए।

**याद रखें:** local notification → EventEmitter; recoverable background work → durable queue। Critical effects के लिए handoff और idempotency भी डिजाइन करें।

जरूरत	EventEmitter	Durable job queue
एक process के components को बताना	सीधा और हल्का	सामान्यतः गैरजरूरी infrastructure जोड़ती है।
Sender बंद होने पर pending work बचाना	Built-in durable record नहीं	सही storage और recovery के साथ संभव।
Retry और backlog देखना	Application को बनाना होगा	सामान्य queue सुविधाएं, configuration के साथ।
दूसरी machines पर काम चलाना	यह उसकी भूमिका नहीं	Workers स्वतंत्र चल सकते हैं।

1. Local notification का रास्ता देखें

2. समझें कि async listener क्या बदलता है

3. Queued task का रास्ता देखें

4. Save और enqueue का अंतर जांचें

5. असली जरूरत के आधार पर तुलना करें

संबंधित प्रश्न