Arquitetura Orientada a Eventos

Em vez de um sistema chamar o outro diretamente e esperar a resposta, na arquitetura orientada a eventos as partes se comunicam por mensagens. Algo aconteceu (um evento), alguém avisa, e quem se interessa reage. Isso desacopla os componentes.

Produtores e consumidores

• Produtor: gera o evento. Ex.: “pedido criado”.
• Consumidor: escuta e reage. Ex.: “enviar e-mail”, “baixar estoque”.

O produtor não sabe quem vai consumir. Ele só anuncia.

Produtor  -->  [ Fila / Broker ]  -->  Consumidor A
                                  -->  Consumidor B

Filas (queues)

Uma fila guarda eventos em ordem até que um consumidor os processe. Útil para trabalho pesado e assíncrono:

[pedido] [pedido] [pedido]  ->  Worker pega um por vez

Se o worker cair, as mensagens esperam. Quando ele volta, continua de onde parou. Cada mensagem normalmente é entregue a um consumidor.

Pub/Sub (publicar/assinar)

No pub/sub, um evento publicado é entregue a todos os assinantes interessados:

Evento "usuário cadastrado"
   -> serviço de e-mail
   -> serviço de analytics
   -> serviço de boas-vindas

Adicionar um novo assinante não muda o produtor.

Assíncrono

O produtor envia e segue a vida, sem esperar o resultado. Isso deixa a resposta ao usuário rápida e distribui o trabalho ao longo do tempo.

Vantagens

• Componentes desacoplados e independentes.
• Escala fácil: adicione mais consumidores.
• Resiliência: picos viram fila, não quedas.

Desvantagens

• Mais difícil de depurar e rastrear o fluxo.
• Consistência é eventual, não imediata.
• Precisa lidar com mensagens duplicadas e ordem.

Quando usar

Ideal quando tarefas podem rodar em segundo plano (e-mails, notificações, processamento de imagens) ou quando vários sistemas precisam reagir ao mesmo fato sem acoplar tudo.