A arquitetura orientada a eventos é um modelo de integração criado para publicação, extração, processamento e armazenamento (ou persistência) de eventos. Quando um aplicativo ou serviço toma uma ação ou inicia uma mudança cujas informações são necessárias para outro aplicativo ou serviço, ele publica um evento, ou seja, um registro dessa ação ou mudança, que outro aplicativo ou serviço pode consumir e processar para tomar ações como resposta.

A arquitetura orientada a eventos permite um acoplamento fraco entre aplicativos e serviços conectados, eles podem se comunicar uns com os outros publicando e consumindo eventos sem ter quaisquer informações uns dos outros, exceto o formato do evento. Esse modelo oferece vantagens significativas sobre uma arquitetura de solicitação/resposta (ou modelo de integração), no qual um aplicativo ou serviço deve solicitar informações específicas de outro aplicativo ou serviço específico que está esperando a solicitação específica.

A arquitetura orientada a eventos maximiza o potencial de aplicativos nativos da cloud e impulsiona tecnologias potentes de aplicativos, como a análise em tempo real e o suporte para decisões.

Em uma arquitetura orientada a eventos, os aplicativos agem como produtores de eventos ou consumidores de eventos (e muitas vezes como ambos).

Um produtor de eventos transmite um evento, no formato de uma mensagem, para um broker ou outra forma de roteador de eventos em que a ordem cronológica do evento é mantida em relação a outros eventos. Um consumidor de eventos ingere a mensagem, em em tempo real (assim que elas surgem) ou em qualquer outro horário escolhido, e processa a mensagem para acionar outra ação, fluxo de trabalho ou seu próprio evento.

Em um exemplo simples, um serviço bancário poderia transmitir um evento 'depósito', que outro serviço no banco consumiria e responderia registrando um depósito no extrato do cliente. Porém, as integrações orientadas a eventos também podem acionar respostas em tempo real, com base na análise complexa de grandes volumes de dados, como o 'evento' quando um cliente clica em um produto de um site de e-commerce e são geradas recomendações instantâneas do produto com base nas compras de outros clientes.

Existem dois modelos básicos de transmissão de eventos em uma arquitetura orientada a eventos

Mensagens de eventos ou modelo publicar/assinar

Nas mensagens de eventos ou no modelo publicar/assinar, os consumidores de eventos fazem uma assinatura em um tipo ou tipos de mensagens publicadas pelos produtores de eventos. Quando um produtor de evento publica um evento, a mensagem é enviada diretamente para todos os assinantes que desejam consumi-la.

Normalmente, um message broker cuida da transmissão de mensagens de eventos de entre editores e assinantes. O broker recebe as mensagens do evento, converte-as se necessário, mantém a ordem dessas mensagens em relação as outras, disponibiliza-as para que os assinantes possam consumi-las e, em seguida, exclui as mensagens após serem consumidas, para que não sejam consumidas novamente.

Fluxo de eventos

No modelo de fluxo de eventos, os produtores de eventos publicam fluxos de eventos em um broker. Os consumidores de eventos fazem uma assinatura para os fluxos, mas, em vez de receber e consumir todos os eventos assim que são publicados, os consumidores podem entrar nos fluxos a qualquer momento e consumir somente os eventos que desejarem. A principal diferença é que os eventos são retidos pelo broker mesmo após o recebimento pelos consumidores.

Uma plataforma de fluxo de dados, como o Apache Kafka, gerencia a criação de logs e a transmissão de volumes enormes de eventos com altíssima produtividade (literalmente trilhões de eventos registrados por dia, em tempo real e sem atrasos no desempenho). Uma plataforma de fluxo oferece determinadas características que um message broker não oferece:

• Persistência de eventos: como os consumidores podem consumir eventos a qualquer momento após serem publicados, os registros de fluxo de eventos são persistentes, ou seja, são mantidos por um período configurável, que pode ser desde frações de segundo até por tempo ilimitado. Isso permite que os aplicativos de fluxo de eventos processem dados históricos, assim como dados em tempo real.
  
  
• Processamento de eventos complexos: assim como as mensagens de eventos, o fluxo de eventos pode ser usado pelo processamento de evento simples, no qual cada evento publicado aciona a transmissão e o processamento de um ou mais consumidores específicos. Porém, ele pode ser usado também para o processamento de eventos complexos, no qual os consumidores de eventos processam séries inteiras de eventos e toma ações baseadas no resultado.

Comparado à arquitetura de aplicativo  de solicitação/resposta, a arquitetura orientada a eventos oferece diversas vantagens e oportunidades para os desenvolvedores e as organizações.

Análise e resposta em tempo real de alta capacidade: os fluxo de eventos impulsiona os aplicativos que respondem às situações de negócios em constante mudança à medida que acontecem e fazem previsões e tomam decisões baseadas nos dados históricos e disponíveis atualmente em tempo real. Isso traz benefícios para diversas áreas, desde os fluxos de processamento de dados gerados por uma ampla variedade de dispositivos IoT, até a previsão e correção de ameaças de segurança à medida que surgem e a automação de cadeias de suprimentos para obter o máximo de eficiência possível.

Tolerância a falhas, escalabilidade, manutenção simplificada, versatilidade e outros benefícios do acoplamento fraco: aplicativos e componentes em um artigo orientado a eventos não dependem da disponibilidade uns dos outros. Eles podem ser atualizados, testados e implementados de maneira independente sem interrupção das operações e, quando um componente se torna inativo, um backup pode ser ativado. A persistência de eventos permite a "reprodução" de eventos passados, o que pode ajudar a recuperar dados ou funcionalidades em caso de interrupção do consumidor de eventos. Os componentes podem ser dimensionados facilmente e de maneira independentemente em toda a rede. Os desenvolvedores podem revisar ou enriquecer aplicativos e sistemas adicionando e removendo produtores e consumidores de eventos.

Mensagens assíncronas: a arquitetura orientada a eventos permite que os componentes se comuniquem de forma assíncrona, ou seja, os produtores podem publicar mensagens de eventos de acordo com seu próprio planejamento, sem esperar até que os consumidores as recebam (ou mesmo sabendo se os consumidores as receberam). Além de simplificar a integração, isso permite aprimorar a experiência do aplicativo para os usuários. Um usuário que concluir uma tarefa em um componente pode iniciar uma nova tarefa sem esperar, independentemente das integrações posteriores entre este componente e outros no sistema.

Nos microsserviços, uma arquitetura de base para aplicativos nativos da cloud, os aplicativos são montados a partir de serviços implementados de forma independente e fracamente acoplados. Os principais benefícios dos microsserviços são basicamente aqueles proporcionados pelo acoplamento fraco: facilidade de manutenção, implementação flexível, ajuste de escala independente e tolerância a falhas.

Não surpreendentemente, arquitetura orientada a eventos é amplamente considerada uma prática recomendada para implementações de microsserviços. Os microsserviços podem comunicar-se uns com os outros usando a API de REST. Mas o REST, um modelo de integração de solicitação/resposta, reduz os benefícios da arquitetura de microsserviços fracamente acoplados por forçar uma integração síncrona e fortemente acoplada entre os  microsserviços.