Qual a diferença entre EventEmitter e uma fila de jobs no Node.js?

Question

IT Interview Practice · Accepted Answer

Escolha entre EventEmitter e uma fila perguntando **onde o trabalho deve executar e o que acontece se o processo parar**.

EventEmitter notifica listeners dentro de um processo Node.js. Uma fila durável guarda trabalho para workers processarem depois. Ambos separam responsabilidades, mas têm comportamentos diferentes diante de falhas.

## 1. Acompanhe uma notificação local

Suponha que um componente termine sua inicialização e queira avisar outros componentes do mesmo processo. EventEmitter é natural: registre os listeners e emita o evento.

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

Node.js chama os listeners sincronamente, na ordem de registro. O evento não fica armazenado para listeners registrados depois, e trabalho inacabado não sobrevive a um crash do processo. [Eventos do Node.js](https://nodejs.org/api/events.html).

Isso funciona quando a notificação é local e pode ser perdida ou reconstruída. É insuficiente quando o negócio espera que o trabalho sobreviva ao emissor.

## 2. Entenda o que um listener async muda

Um listener async pode iniciar trabalho assíncrono, mas emit não espera sua promise. A ordem das chamadas não é necessariamente a ordem de conclusão.

Código síncrono pesado em CPU dentro do listener ainda atrasa o processo. Trate erros lançados e promises rejeitadas; captureRejections pode encaminhar rejeições ao tratamento de erros, mas não persiste nem repete a tarefa.

Adicionar async muda como o listener trabalha. Não transforma um evento em memória em fila durável.

## 3. Acompanhe uma tarefa enfileirada

Agora suponha que salvar um pedido deva gerar uma fatura posteriormente. Uma fila guarda a instrução enquanto workers estão ocupados ou indisponíveis.

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

O produtor envia o job; um worker processa uma tentativa e registra o resultado. Workers podem ser implantados e escalados separadamente da API. A durabilidade ainda depende do armazenamento e da configuração da fila.

Em uma fila típica de workers concorrentes, um worker trata cada tentativa. Isso difere de transmitir um evento a todos os listeners. Se vários assinantes independentes precisam receber o evento, escolha ou configure um modelo de entrega compatível.

## 4. Verifique a lacuna entre salvar e enfileirar

Com EventEmitter, um crash após salvar o pedido e antes de emitir pode perder a instrução da fatura. Uma fila durável protege o job depois de aceitá-lo, mas não protege automaticamente a lacuna anterior entre commit e envio.

Uma outbox fecha essa lacuna salvando pedido e instrução na mesma transação. Um publicador lê a outbox e envia o job depois.

A entrega pode repetir se o publicador perder a confirmação. Dê à criação da fatura uma chave estável e restrição única, ou outra implementação idempotente. Repetir a tentativa não deve criar outra fatura. [Jobs idempotentes](https://docs.bullmq.io/patterns/idempotent-jobs).

## 5. Compare com a necessidade real

| Requisito | EventEmitter | Fila durável |
| --- | --- | --- |
| Notificar componentes no mesmo processo | Direto e leve | Geralmente adiciona infraestrutura desnecessária. |
| Manter trabalho após o emissor parar | Sem registro durável integrado | Possível com armazenamento e recuperação adequados. |
| Repetir e inspecionar pendências | A aplicação precisa construir isso | Capacidades comuns de filas, com configuração. |
| Executar em outras máquinas | Não é seu papel | Workers executam independentemente. |

Para inicialização, eu usaria EventEmitter. Para faturamento que precisa se recuperar de falhas, escolheria fila durável, cuidando da transferência do banco e das tentativas duplicadas.

Teste parando o processo nos limites importantes: antes do envio, após a aceitação e depois do efeito de negócio. O resultado deve corresponder à garantia esperada pelo usuário.

**Lembre-se:** notificação local → EventEmitter; trabalho recuperável em segundo plano → fila durável. Para efeitos críticos, projete também a transferência e a idempotência.

Requisito	EventEmitter	Fila durável
Notificar componentes no mesmo processo	Direto e leve	Geralmente adiciona infraestrutura desnecessária.
Manter trabalho após o emissor parar	Sem registro durável integrado	Possível com armazenamento e recuperação adequados.
Repetir e inspecionar pendências	A aplicação precisa construir isso	Capacidades comuns de filas, com configuração.
Executar em outras máquinas	Não é seu papel	Workers executam independentemente.

1. Acompanhe uma notificação local

2. Entenda o que um listener async muda

3. Acompanhe uma tarefa enfileirada

4. Verifique a lacuna entre salvar e enfileirar

5. Compare com a necessidade real

Perguntas relacionadas