Node.js‌లో EventEmitter, job queue మధ్య తేడా ఏమిటి?

Question

IT Interview Practice · Accepted Answer

EventEmitter లేదా job queue ఎంచుకోవడానికి **పని ఎక్కడ నడవాలి, process ఆగితే ఏమవుతుంది** అని అడగండి.

EventEmitter ఒక Node.js process లో listeners కు తెలియజేస్తుంది. Durable queue పనిని నిల్వ చేసి తర్వాత workers తో ప్రాసెస్ చేయిస్తుంది. రెండూ బాధ్యతలను విడదీస్తాయి, కానీ వైఫల్యం వచ్చినప్పుడు ప్రవర్తన వేరు.

## 1. స్థానిక notification ను అనుసరించండి

ఒక component initialization పూర్తిచేసి అదే process లోని ఇతర components స్పందించాలని అనుకుంటుందనుకోండి. EventEmitter సహజమైన ఎంపిక: listeners నమోదు చేసి event emit చేయండి.

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

Node.js నమోదైన listeners ను నమోదు క్రమంలో synchronously పిలుస్తుంది. తర్వాత నమోదయ్యే listeners కోసం event నిల్వ ఉండదు; పూర్తి కాని పని process crash తర్వాత నిలవదు. [Node.js Events](https://nodejs.org/api/events.html).

Notification స్థానికమైనది, పోయినా పరవాలేనిది లేదా తిరిగి నిర్మించగలదైతే ఇది పనిచేస్తుంది. Sender ఆగిన తర్వాత కూడా పని నిలవాలని business ఆశిస్తే ఇది సరిపోదు.

## 2. Async listener ఏమి మారుస్తుందో అర్థం చేసుకోండి

Async listener asynchronous పనిని ప్రారంభించవచ్చు, కానీ అది ఇచ్చే promise కోసం emit వేచి ఉండదు. అందువల్ల పిలిచిన క్రమంలోనే పూర్తవ్వాలని లేదు.

ఆ listener లో CPU ఎక్కువగా వాడే synchronous code process ను ఇంకా ఆలస్యం చేస్తుంది. Thrown errors, rejected promises ను ఉద్దేశపూర్వకంగా నిర్వహించండి; captureRejections వాటిని error handling కి పంపగలదు కానీ task ను నిల్వ చేయదు లేదా retry చేయదు.

Async చేర్చడం listener పని చేసే విధానాన్ని మారుస్తుంది. Memory లోని event ను durable queue గా మార్చదు.

## 3. Queue లోని పనిని అనుసరించండి

ఇప్పుడు order సేవ్ చేసినప్పుడు చివరికి invoice తయారవ్వాలని అనుకోండి. Workers అందుబాటులో లేకపోయినా లేదా busy గా ఉన్నా instruction ఉంచడానికి queue చోటిస్తుంది.

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

Producer job సమర్పిస్తుంది; worker ఒక attempt ను ప్రాసెస్ చేసి ఫలితాన్ని నమోదు చేస్తుంది. Workers ను API నుంచి విడిగా deploy, scale చేయవచ్చు. Durability ఇంకా queue storage, configuration పై ఆధారపడుతుంది.

సాధారణ competing-worker queue లో ఒక్కో attempt ను ఒక worker నిర్వహిస్తుంది. ఇది ప్రతి EventEmitter listener కు event broadcast చేయడం కంటే భిన్నం. స్వతంత్ర subscribers ప్రతి ఒక్కరికీ event అవసరమైతే ఆ అవసరాన్ని నెరవేర్చే delivery model ఎంచుకోండి లేదా configure చేయండి.

## 4. సేవ్ చేయడానికి, enqueue చేయడానికి మధ్య ఖాళీని పరిశీలించండి

EventEmitter లో order సేవ్ అయిన తర్వాత emit చేయకముందు crash అయితే invoice instruction పోవచ్చు. Durable queue job ను స్వీకరించిన తర్వాత రక్షిస్తుంది; database commit, submission మధ్య అంతకుముందున్న ఖాళీని స్వయంగా రక్షించదు.

Outbox order ను, దాని instruction ను అదే database transaction లో నిల్వ చేసి ఆ ఖాళీని మూస్తుంది. Publisher outbox చదివి job ను తర్వాత పంపుతుంది.

Publisher confirmation కోల్పోతే delivery పునరావృతం కావచ్చు. Invoice creation కు స్థిరమైన 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 నిర్మించాలి | Configuration తో సాధారణ queue సామర్థ్యాలు. |
| ఇతర machines లో పని నడపడం | దాని పాత్ర కాదు | Workers స్వతంత్రంగా నడవవచ్చు. |

Initialization ఉదాహరణకు EventEmitter వాడతాను. Failure నుంచి కోలుకోవాల్సిన invoice generation కు durable queue వాడి database handoff, duplicate attempts ను పరిష్కరిస్తాను.

ముఖ్యమైన సరిహద్దుల్లో process ను ఆపి పరీక్షించండి: submission ముందు, acceptance తర్వాత, business effect తర్వాత. ఫలితం వినియోగదారు ఆశించే హామీతో సరిపోవాలి.

**గుర్తుంచుకోండి:** స్థానిక notification → EventEmitter; తిరిగి కోలుకోగల background work → durable queue. కీలక ప్రభావాలకు handoff, idempotency కూడా రూపకల్పన చేయండి.

అవసరం	EventEmitter	Durable job queue
ఒక process లో components కు తెలియజేయడం	నేరుగా, తేలికగా ఉంటుంది	సాధారణంగా అనవసర infrastructure చేరుస్తుంది.
Sender ఆగిన తర్వాత pending work ఉంచడం	Built-in durable record లేదు	తగిన storage, recovery తో సాధ్యం.
Retry, backlog పరిశీలన	Application నిర్మించాలి	Configuration తో సాధారణ queue సామర్థ్యాలు.
ఇతర machines లో పని నడపడం	దాని పాత్ర కాదు	Workers స్వతంత్రంగా నడవవచ్చు.

1. స్థానిక notification ను అనుసరించండి

2. Async listener ఏమి మారుస్తుందో అర్థం చేసుకోండి

3. Queue లోని పనిని అనుసరించండి

4. సేవ్ చేయడానికి, enqueue చేయడానికి మధ్య ఖాళీని పరిశీలించండి

5. నిజమైన అవసరంతో ఎంపికలను పోల్చండి

సంబంధిత ప్రశ్నలు