Arquitetura Orientada a Eventos: como funciona e quando usar

O que é arquitetura orientada a eventos?

Arquitetura orientada a eventos, também chamada de event-driven architecture ou EDA, é um estilo em que componentes publicam acontecimentos relevantes e outros componentes reagem a eles.

Um evento registra um fato do domínio, como “pagamento aprovado”, “arquivo recebido” ou “temperatura alterada”.

A definição do Azure Architecture Center divide esse modelo em produtores, consumidores e canais de eventos.

O produtor não precisa aguardar que todos os consumidores terminem nem conhecer suas implementações.

Essa independência espacial e temporal é a base do desacoplamento.

Nem todo uso de fila torna um sistema orientado a eventos. Se um serviço envia uma instrução específica para outro executar, há comunicação assíncrona, mas a intenção pode continuar fortemente direcionada.

O desenho se torna orientado a eventos quando acontecimentos do negócio orientam reações e evolução do fluxo.

Quais são os componentes principais?

• Produtor: detecta uma mudança e publica o evento, sem determinar todos os usos futuros.
• Evento: registro imutável do fato, com identificador, tipo, instante, origem e dados necessários.
• Canal ou broker: recebe, armazena ou roteia eventos conforme o modelo adotado.
• Consumidor: assina os eventos relevantes e executa uma reação.
• Políticas operacionais: controlam retenção, repetição, expiração, ordenação e tratamento de falhas.
• Observabilidade: permite correlacionar o caminho do evento entre serviços.

Broker é um papel, não uma tecnologia única. Ele pode atuar como fila, barramento de publicação e assinatura ou plataforma de streaming.

A escolha muda as garantias disponíveis e a maneira como consumidores acompanham o fluxo.

Evento, mensagem e comando: qual é a diferença?

Conceito	Significado	Exemplo	Expectativa
Mensagem	Envelope de comunicação que transporta dados	Conteúdo enviado por uma fila	Depende do tipo transportado
Comando	Pedido para que uma ação seja executada	ReservarEstoque	Um responsável deve aceitar ou rejeitar
Evento	Fato que já aconteceu	PagamentoAprovado	Zero, um ou vários consumidores podem reagir

Nomes no passado ajudam a comunicar que o evento não é uma solicitação.

O produtor não deveria publicar “EnviarEmail” como se estivesse descrevendo um fato; “PedidoConfirmado” permite que notificação, dados e logística decidam suas próprias reações.

A distinção também evita responsabilidades escondidas. Um evento deve representar algo verdadeiro no domínio.

Se a operação ainda pode falhar ou ser recusada, provavelmente há um comando antes do evento correspondente.

Como funciona na prática

Considere um e-commerce. O serviço de pagamentos confirma uma transação, grava seu estado e publica um evento com identificador, pedido, instante e versão do contrato.

O broker disponibiliza o registro para consumidores interessados.

1. Estoque recebe o evento e tenta reservar os itens.
2. Notificações prepara a confirmação para o cliente.
3. Antifraude atualiza seus sinais e histórico.
4. Analytics registra a conversão.
5. Novos consumidores podem ser acrescentados sem alterar pagamentos.

Cada reação possui seu próprio tempo. Analytics pode processar depois, enquanto estoque exige baixa latência.

Se notificações estiver temporariamente indisponível, os demais consumidores continuam.

Esse isolamento é valioso, mas exige que cada componente saiba retomar o processamento.

Publicação, assinatura e streaming

No modelo de publicação e assinatura, cada assinatura lógica recebe sua própria cópia ou referência ao evento.

É adequado quando vários processos independentes devem reagir ao mesmo fato.

Dentro de um grupo, instâncias podem dividir o trabalho para aumentar capacidade.

Em streaming, eventos permanecem por um período e consumidores mantêm sua posição de leitura.

Isso permite reproduzir o histórico, criar novas projeções e processar grandes sequências.

A documentação de design do Apache Kafka mostra como log, partições e offsets sustentam esse modelo.

Filas são úteis quando um trabalho deve ser executado por um consumidor do grupo. Pub/sub favorece distribuição para múltiplos interessados.

Streams favorecem retenção, replay e processamento contínuo. Plataformas podem combinar características, portanto a decisão deve começar pelas garantias necessárias.

Diferentes formas de representar eventos

• Notificação simples: informa que algo mudou e carrega identificadores mínimos. O consumidor consulta detalhes na origem.
• Transferência de estado: inclui os dados necessários para que o consumidor atualize sua própria visão sem chamada adicional.
• Evento de domínio: expressa um fato importante segundo a linguagem do negócio.
• Evento de integração: é preparado como contrato estável para atravessar limites entre sistemas.

Eventos muito pobres criam consultas síncronas e devolvem acoplamento à origem. Eventos grandes demais expõem dados desnecessários, aumentam custo e dificultam evolução.

Publique o mínimo suficiente para a reação autorizada, com identificadores e metadados para rastreabilidade.

A especificação CloudEvents propõe uma forma comum de descrever metadados de eventos entre serviços e plataformas.

Ela não define o conteúdo do domínio, mas ajuda a padronizar atributos como origem, tipo, identificador e horário.

Principais benefícios

• Baixo acoplamento: produtores não precisam conhecer todos os consumidores.
• Extensibilidade: uma nova reação pode ser adicionada sem modificar o fluxo original.
• Escalabilidade independente: consumidores aumentam capacidade conforme sua carga.
• Absorção de picos: o canal mantém eventos enquanto consumidores processam no ritmo possível.
• Resiliência parcial: indisponibilidade de um consumidor não precisa interromper todos.
• Processamento em tempo próximo do real: mudanças podem acionar respostas rapidamente.
• Replay: quando a infraestrutura retém histórico, consumidores podem reconstruir projeções.

Esses ganhos aparecem principalmente em domínios com reações múltiplas e evolução independente.

Eles não são automáticos: um evento mal definido pode apenas deslocar dependências do código para contratos implícitos e difíceis de localizar.

Desafios que a arquitetura introduz

O fluxo deixa de estar visível em uma única pilha de chamadas. Um pedido pode atravessar vários serviços durante segundos ou minutos, e cada um pode estar em um estado diferente.

Depuração, teste integrado e suporte ficam mais complexos.

• Duplicidade e reprocessamento;
• ordenação apenas dentro de determinados limites;
• eventos atrasados ou expirados;
• falhas parciais e compensações;
• evolução de contratos com consumidores desconhecidos;
• crescimento de tópicos, assinaturas e custos;
• dificuldade de apagar dados distribuídos;
• necessidade de observabilidade ponta a ponta.

A arquitetura reduz acoplamento de disponibilidade, mas aumenta a necessidade de disciplina operacional.

Isso explica por que microsserviços e eventos não devem ser adotados apenas por tendência.

Garantias de entrega e duplicidade

Garantia	Possível resultado	Responsabilidade
No máximo uma vez	Evento pode ser perdido, mas não repetido pelo canal	Adequada somente quando perda é aceitável
Pelo menos uma vez	Evento não deve ser perdido, porém pode chegar novamente	Consumidor precisa ser idempotente
Exatamente uma vez	Efeito aparece uma vez dentro de um limite definido	Exige condições específicas e não deve ser presumida ponta a ponta

Na prática, “pelo menos uma vez” é comum. Se o consumidor conclui a operação e falha antes de confirmar, o broker pode reenviar.

O consumidor deve reconhecer o identificador ou tornar a alteração naturalmente idempotente, para que a repetição não cobre duas vezes nem reserve estoque duplicado.

Após falhas transitórias, aplique repetição com espera e limite. Eventos que continuam falhando vão para uma área de quarentena ou fila de mensagens mortas, acompanhados de contexto para investigação. Reprocessar sem corrigir a causa apenas cria um ciclo de erro.

Ordenação, atraso e tempo do evento

Ordenação global reduz paralelismo e raramente é necessária. Normalmente, basta preservar a sequência por entidade, como pedido ou conta.

Para isso, eventos relacionados usam a mesma chave de particionamento e são processados de forma compatível com a garantia do canal.

Ainda assim, redes, repetição e produtores diferentes podem causar atrasos.

Consumidores devem decidir o que fazer com uma atualização mais antiga: ignorar por versão, reordenar em uma janela, recalcular estado ou encaminhar para análise.

Registre separadamente o instante em que o fato ocorreu e o momento em que foi processado. Essa diferença é decisiva em telemetria, fraude, IoT e análises baseadas em janelas de tempo.

Consistência eventual e falhas parciais

Após a publicação, consumidores podem levar tempos diferentes para refletir a mudança. Durante esse intervalo, leituras em sistemas distintos podem divergir.

Isso é consistência eventual: se não surgirem novas alterações e o processamento continuar, as visões tendem a convergir.

A experiência do usuário precisa reconhecer esse comportamento. Uma interface pode mostrar “processando” em vez de afirmar que todas as etapas terminaram.

Quando a reserva de estoque falha após o pagamento, o negócio deve ter compensação definida, como estorno ou atendimento.

Outro problema é gravar no banco e publicar o evento como duas operações separadas.

Se uma funcionar e outra falhar, o estado se perde. Padrões como outbox transacional registram a alteração e a intenção de publicação na mesma transação local, deixando um processo confiável encaminhar o evento.

Contratos e evolução de esquemas

Eventos são APIs assíncronas. Campo, tipo, semântica, unidade, obrigatoriedade e política de dados formam um contrato entre equipes. Documente proprietário, propósito, exemplos, versão, retenção e compatibilidade.

• Prefira adicionar campos opcionais a remover ou mudar significados.
• Consumidores devem ignorar campos desconhecidos quando o formato permitir.
• Não reutilize um nome antigo para um fato diferente.
• Teste contratos entre produtores e consumidores.
• Mantenha período de migração quando houver mudança incompatível.
• Evite publicar dados que nenhum consumidor autorizado necessita.

Catálogos e registros de esquema ajudam a descobrir eventos e validar compatibilidade, mas não substituem comunicação sobre significado. Um campo tecnicamente válido ainda pode ser interpretado de forma errada.

Observabilidade em fluxos assíncronos

Cada evento deve carregar ou propagar identificadores de correlação. Traces distribuídos conectam publicação, espera no broker e processamento em consumidores.

O conteúdo sobre OpenTelemetry explica como correlacionar traces, métricas e logs entre serviços.

• Taxa de publicação e consumo;
• atraso do consumidor em relação ao fluxo;
• tempo no canal e duração de processamento;
• tentativas, falhas e eventos em quarentena;
• idade do evento mais antigo pendente;
• distribuição por tipo e versão de contrato;
• resultados de negócio, não apenas saúde técnica.

Alertas devem indicar impacto e ação possível. Fila acumulada pode ser normal durante um pico curto; crescimento contínuo com aumento da idade é um sinal mais útil.

Para uma visão ampla, consulte também o guia de observabilidade e monitoramento.

Segurança e governança

• Autentique produtores e consumidores e aplique autorização por tópico ou fila.
• Criptografe dados em trânsito e em repouso conforme o risco.
• Minimize informações pessoais e segredos no payload.
• Defina retenção, descarte e atendimento a solicitações de exclusão.
• Valide tamanho, tipo, versão e origem antes do processamento.
• Controle quem pode criar canais, alterar políticas ou reproduzir eventos.
• Audite acessos administrativos e operações de reprocessamento.

Eventos não são confiáveis apenas porque circulam dentro da rede. Um consumidor comprometido pode publicar dados falsos ou explorar outro serviço com payloads malformados.

Trate o canal como uma fronteira de segurança e limite privilégios.

Quando usar arquitetura orientada a eventos

• Um acontecimento precisa acionar vários processos independentes.
• Produtores e consumidores evoluem e escalam em ritmos diferentes.
• Picos precisam ser absorvidos sem sobrecarregar serviços.
• O fluxo tolera resposta assíncrona e consistência eventual.
• Novas reações devem ser adicionadas sem modificar a origem.
• Há necessidade de streaming, histórico ou reconstrução de projeções.
• Dispositivos, sistemas externos ou dados operacionais geram mudanças contínuas.

Integrações por webhooks também notificam acontecimentos, mas normalmente usam entrega HTTP direta.

Um broker acrescenta retenção, assinaturas, repetição e controle operacional mais rico. Já o Change Data Capture pode transformar alterações do banco em eventos para integração.

Quando evitar

Evite adicionar eventos quando uma chamada síncrona simples resolve a necessidade com clareza, especialmente em aplicações pequenas, equipes sem operação de mensageria ou fluxos que exigem resposta imediata e consistente em uma única transação.

• Há apenas um produtor e um consumidor estáveis, sem pressão de escala.
• O usuário precisa receber o resultado definitivo antes de continuar.
• A equipe não consegue monitorar filas, contratos e reprocessamento.
• O domínio ainda não possui limites e fatos bem compreendidos.
• A complexidade foi escolhida apenas para imitar arquiteturas de grandes empresas.

APIs REST continuam adequadas para consultas e comandos com resposta imediata.

Sistemas maduros frequentemente combinam chamadas síncronas para interações diretas e eventos para propagação de fatos.

Como escolher o tipo de infraestrutura

Necessidade dominante	Modelo inicial	Perguntas importantes
Executar um trabalho por vez	Fila	Como funcionam confirmação, repetição e mensagens mortas?
Notificar vários interessados	Publicação e assinatura	Cada assinatura recebe e retém sua cópia?
Reter, reproduzir e processar sequência	Stream ou log distribuído	Qual é a garantia por partição e a política de retenção?
Entregar evento a endpoints HTTP	Roteador de eventos	Como funcionam autenticação, repetição e expiração?

Compare volume, tamanho, latência, retenção, ordenação, replay, disponibilidade regional, modelo de consumo, operação e custo.

Não escolha apenas pelo maior throughput anunciado: garantias e simplicidade operacional costumam determinar o sucesso.

Como implementar com segurança

1. Escolha um fluxo com benefício claro e identifique os fatos do domínio.
2. Defina proprietário, contrato, identificador, chave e política de dados.
3. Selecione a infraestrutura pelas garantias necessárias.
4. Implemente publicação confiável junto à mudança de estado.
5. Crie consumidores idempotentes e limite tentativas.
6. Configure quarentena, alertas e procedimento de reprocessamento.
7. Propague correlação e instrumente o fluxo ponta a ponta.
8. Teste duplicidade, atraso, fora de ordem, indisponibilidade e pico.
9. Documente compensações e expectativas de consistência.
10. Comece pequeno e amplie após validar a operação.

Erros comuns

• Publicar comandos disfarçados de eventos: o produtor continua controlando consumidores.
• Presumir entrega exatamente uma vez: efeitos externos ainda podem duplicar.
• Não planejar idempotência: uma repetição normal vira incidente de negócio.
• Exigir ordenação global: throughput cai para preservar uma garantia desnecessária.
• Ignorar evolução do contrato: uma mudança quebra consumidores que o produtor desconhece.
• Usar o banco como fila improvisada: concorrência, retenção e monitoramento ficam frágeis.
• Não ter observabilidade: o time sabe que algo falhou, mas não encontra onde.
• Distribuir dados demais: cada cópia amplia risco de segurança e governança.

Perguntas frequentes

Arquitetura orientada a eventos exige microsserviços?

Não. Um monólito modular pode publicar e consumir eventos internamente ou integrar processos externos. Microsserviços tornam os limites de rede mais visíveis, mas não são requisito.

Fila e evento são a mesma coisa?

Não. Fila é um mecanismo de entrega; evento é um fato. Filas podem transportar comandos, eventos ou outros tipos de mensagem.

Kafka é obrigatório para event-driven architecture?

Não. Kafka é uma plataforma de streaming, mas filas, serviços de pub/sub, roteadores e brokers diferentes podem atender outros requisitos com menor complexidade.

Como evitar processar um evento duas vezes?

Use um identificador estável, registre o processamento ou desenvolva uma operação cujo resultado não muda quando repetida. A estratégia depende do efeito e do armazenamento.

O que acontece quando um consumidor fica fora do ar?

Se o canal retém eventos, eles permanecem disponíveis até o consumidor voltar, dentro da política configurada. É preciso monitorar atraso, capacidade e expiração.

Event sourcing é o mesmo que arquitetura orientada a eventos?

Não. Event sourcing armazena o estado como uma sequência de eventos, conforme explica o padrão Event Sourcing da Microsoft. Uma arquitetura pode trocar eventos sem usar esse modelo de persistência.

Conclusão

Arquitetura orientada a eventos permite que sistemas reajam a fatos sem criar chamadas diretas entre todos os participantes.

Ela funciona especialmente bem quando há múltiplos consumidores, picos, processamento independente e necessidade de acrescentar novas reações.

O preço do desacoplamento é lidar explicitamente com duplicidade, atraso, consistência eventual, contratos e falhas parciais.

Comece por um fluxo que realmente se beneficie, escolha a infraestrutura pelas garantias e projete a operação antes de escalar.

O melhor sistema event-driven não é o que possui mais eventos, mas o que torna mudanças importantes confiáveis e compreensíveis.