Node.jsમાં EventEmitter અને job queue વચ્ચે શું તફાવત છે?

Question

IT Interview Practice · Accepted Answer

EventEmitter અને job queue વચ્ચે પસંદગી માટે પૂછો કે **કામ ક્યાં ચાલવું જોઈએ અને process બંધ થાય તો શું થવું જોઈએ**.

EventEmitter એક Node.js processની અંદરના listenersને જાણ કરે છે. Durable queue પછી workers ચલાવી શકે તે માટે કામ સાચવે છે. બંને જવાબદારીઓ અલગ કરે છે, પરંતુ નિષ્ફળતામાં તેમનું વર્તન જુદું છે.

## 1. Local notificationનો માર્ગ જુઓ

માનો કે componentનું initialization પૂરું થાય અને એ જ processના બીજા componentsએ પ્રતિસાદ આપવો હોય. EventEmitter સ્વાભાવિક વિકલ્પ છે: listeners નોંધો અને event emit કરો.

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

Node.js listenersને નોંધણીના ક્રમમાં synchronously બોલાવે છે. પછી નોંધાતા listener માટે 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ની રાહ જોતું નથી. એટલે બોલાવવાનો ક્રમ અને પૂર્ણ થવાનો ક્રમ જરૂરી નથી કે સમાન હોય.

એ listenerની અંદર CPU-heavy synchronous code હજી processને મોડું કરે છે. Thrown errors અને rejected promises સ્પષ્ટ રીતે સંભાળો; captureRejections rejectionને error handling તરફ મોકલી શકે છે, પરંતુ task સાચવતું કે retry કરતું નથી.

Async ઉમેરવાથી listener કામ કેવી રીતે કરે છે તે બદલાય છે. Memoryમાંના eventને durable queue બનાવતું નથી.

## 3. Queueમાંના taskનો માર્ગ જુઓ

હવે માનો કે order સાચવ્યા પછી અંતે invoice બનવું જ જોઈએ. Workers ઉપલબ્ધ ન હોય કે વ્યસ્ત હોય ત્યારે 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 કરવાથી જુદું છે. ઘણા independent subscribersને event જોઈએ તો તે જરૂરિયાતને સમર્થન આપતું delivery model પસંદ કે configure કરો.

## 4. સાચવવા અને queueમાં મૂકવા વચ્ચેનું અંતર તપાસો

EventEmitter સાથે order સાચવ્યા પછી પણ 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 રીત રાખો. Attempt ફરી થાય તો બીજું invoice ન બનવું જોઈએ. [Idempotent jobs](https://docs.bullmq.io/patterns/idempotent-jobs).

## 5. વાસ્તવિક જરૂરિયાત સામે વિકલ્પો સરખાવો

| જરૂરિયાત | EventEmitter | Durable job queue |
| --- | --- | --- |
| એક processના componentsને જાણ કરવી | સીધું અને હળવું | સામાન્ય રીતે બિનજરૂરી infrastructure ઉમેરે. |
| Sender બંધ થયા પછી pending કામ રાખવું | Built-in durable record નથી | યોગ્ય storage અને recovery સાથે શક્ય. |
| Retry અને backlog તપાસવો | Applicationએ બનાવવું પડે | સામાન્ય queue ક્ષમતાઓ, configuration સાથે. |
| બીજા machine પર કામ ચલાવવું | તેની ભૂમિકા નથી | Workers સ્વતંત્ર રીતે ચાલી શકે. |

Initialization માટે હું EventEmitter વાપરું. Failure પછી પુનઃપ્રાપ્તિ જરૂરી એવા invoice generation માટે durable queue વાપરું અને database handoff તથા duplicate attemptsનું નિરાકરણ કરું.

મહત્વની સીમાઓ પર process બંધ કરીને તપાસો: submission પહેલાં, acceptance પછી અને business effect પછી. પરિણામ userની અપેક્ષિત ગેરંટી સાથે મેળ ખાતું હોવું જોઈએ.

**યાદ રાખો:** local notification → EventEmitter; પુનઃપ્રાપ્તિ લાયક background કામ → durable queue. Critical effects માટે handoff અને idempotency પણ ડિઝાઇન કરો.

જરૂરિયાત	EventEmitter	Durable job queue
એક processના componentsને જાણ કરવી	સીધું અને હળવું	સામાન્ય રીતે બિનજરૂરી infrastructure ઉમેરે.
Sender બંધ થયા પછી pending કામ રાખવું	Built-in durable record નથી	યોગ્ય storage અને recovery સાથે શક્ય.
Retry અને backlog તપાસવો	Applicationએ બનાવવું પડે	સામાન્ય queue ક્ષમતાઓ, configuration સાથે.
બીજા machine પર કામ ચલાવવું	તેની ભૂમિકા નથી	Workers સ્વતંત્ર રીતે ચાલી શકે.

1. Local notificationનો માર્ગ જુઓ

2. Async listener શું બદલે છે તે સમજો

3. Queueમાંના taskનો માર્ગ જુઓ

4. સાચવવા અને queueમાં મૂકવા વચ્ચેનું અંતર તપાસો

5. વાસ્તવિક જરૂરિયાત સામે વિકલ્પો સરખાવો

સંબંધિત પ્રશ્નો