O que é arquitetura baseada em eventos?

Permite que as equipes identifiquem eventos do sistema (basicamente, qualquer mudança ou ação que ocorra dentro do sistema) e respondam e reajam a eles em tempo real (ou quase em tempo real).

A profusão de EDAs em ambientes nativos da nuvem representa uma mudança significativa das arquiteturas computacionais tradicionais, que se concentram em armazenar dados estáticos em repositórios como data lakes (como nas arquiteturas orientadas a serviços), em direção a uma abordagem dinâmica que rastreia os dados enquanto atravessam uma arquitetura. Os dados ainda são valiosos em um sistema baseado em eventos, mas as EDAs enfatizam a reação oportuna aos eventos, reconhecendo que o valor de um evento pode diminuir à medida que o tempo avança.

Em uma arquitetura baseada em eventos, produtores de eventos (como microsserviços, APIs e dispositivos de IoT) enviam event notifications em tempo real para consumidores de eventos que, em seguida, ativam rotinas de processamento específicas. Por exemplo, quando a Netflix lança uma nova série original, vários serviços de EDA aguardam em espera pela notificação do lançamento, o que aciona uma cascata de atualizações para informar os usuários.

Uma das principais vantagens de uma arquitetura baseada em eventos é a relação desacoplada entre os componentes de front-end e back-end, o que permite que os sistemas compartilhem informações sem conhecerem uns sobre os outros. Os produtores podem enviar eventos sem saber qual consumidor os receberá, e os consumidores podem receber eventos sem enviar solicitações aos produtores. Em outras palavras, as EDAs permitem que os sistemas trabalhem de forma independente e processem eventos de forma assíncrona.

Empresas modernas e com visão de futuro têm vastas pegadas digitais, e a funcionalidade em tempo real de um sistema baseado em eventos permite que as empresas mantenham a prontidão operacional sem ficar ociosas e respondam rapidamente às transmissões de eventos. Dessa forma, as EDAs ajudam as empresas a automatizar uma série de processos organizacionais, desde a otimização das cadeias de suprimentos até a identificação proativa de problemas de qualidade, e, em última análise, a melhorar seus resultados.

O fluxo de eventos gira em torno do fluxo ilimitado, sequencial e em tempo real de registros de dados chamados "eventos", estruturas de dados fundamentais que registram qualquer ocorrência ou mudança no sistema ou ambiente. Exemplos dessas alterações incluem um usuário que adiciona um item ao carrinho de compras em um site de comércio eletrônico, solicita a redefinição de senha ou uma alteração de estado de uma aplicação. É um termo que essencialmente se refere a cada ponto de dados no sistema. E um "fluxo" (também chamado de fluxo de dados ou dados de streaming) é a entrega contínua desses eventos.

Cada evento normalmente inclui uma chave que identifica o evento ou a entidade a que se refere, um valor que contém os dados reais do evento, um registro de data e hora que indica quando o evento ocorreu ou foi registrado e, às vezes, metadados sobre a fonte de dados, versão do esquema ou outro atributo. Eles podem conter dados de estado (o item comprado, seu preço e um endereço de entrega, por exemplo) ou servir como identificadores (uma notificação de envio).

Com a ajuda de mecanismos especializados de processamento de fluxos, os eventos podem passar por diferentes processos dentro de um fluxo. As "Agregações" realizam cálculos de dados, como médias, somas e desvio padrão. A "ingestão" adiciona dados em fluxo a bancos de dados. O processamento analítico usa padrões em dados de fluxo para prever eventos futuros, e o processamento de enriquecimento combina pontos de dados com outras fontes para fornecer contexto e gerar significado.

Eventos estão frequentemente ligados a operações de negócios ou processos de navegação do usuário e geralmente desencadeiam outra ação, processo ou série de eventos. Por exemplo, considere o internet banking. Quando um usuário clica em "transferir" para enviar dinheiro de uma conta bancária para outra, os fundos são retirados da conta do remetente e adicionados à conta do destinatário, notificações por e-mail ou SMS são enviadas para uma ou ambas as partes e, se necessário, protocolos de segurança e prevenção de fraude são implementados.

Além dos eventos, as EDAs dependem de três componentes principais para migrar dados de eventos através da arquitetura.

• Produtores de eventos(ou editores):  os produtores são as fontes dos eventos; eles geram eventos e os enviam para o resto do sistema.  Um produtor pode ser uma interface de usuário, um sensor, um serviço ou qualquer outro sistema capaz de detectar ou produzir uma mudança de estado de interesse para outras partes do sistema. Embora os produtores sejam responsáveis pela criação de eventos, eles não têm funcionalidade de processamento de eventos.

• Consumidores de eventos (ou assinantes): os consumidores lidam com as tarefas de processamento de eventos em uma EDA. Eles ouvem em canais de eventos e reagem quando um evento de interesse é publicado. A reação pode assumir muitas formas, incluindo a atualização de um banco de dados, o acionamento de um processo subsequente ou simplesmente o registro de informações.

• Roteadores de eventos (ou orquestradores de eventos): roteadores ou orquestradores, são os brokers que separam produtores de eventos de front-end de consumidores de eventos de back-end; eles atuam como canais por meio dos quais os eventos são entregues, garantindo a transmissão sem a necessidade de uma conexão direta entre as entidades. Os roteadores podem ser baseados em componentes convencionais (middleware orientado a mensagens, como um SaaS, por exemplo) e ser úteis em uma variedade de sistemas de mensagens (filas de mensagens, modelos de publicação/assinatura, event streams e outros.).

Em uma EDA, aplicações orientadas a eventos atuam como produtores ou consumidores (e às vezes ambos).

Quando um aplicativo ou serviço executa uma ação que outro aplicativo ou serviço pode querer saber, ele publica um novo evento (um registro dessa ação ou alteração) que outro serviço pode consumir e processar para executar outras ações.

Em seguida, o produtor de eventos transmite o evento (na forma de uma mensagem) para um broker ou outro tipo de roteador de eventos, que mantém a ordem cronológica do evento em relação a outros eventos. Um consumidor de eventos realiza a ingestão da mensagem — em tempo real (conforme ela ocorre) ou em uma instância relevante posterior — e processa a mensagem para acionar outra ação, fluxo de trabalho ou evento próprio.

Em um exemplo simples, um serviço bancário pode transmitir um evento de "depósito", que outro serviço bancário consumiria e responderia escrevendo um depósito no extrato do cliente.

Mas as integrações baseadas em eventos também podem acionar respostas em tempo real com base em análises complexas de grandes volumes de dados, como quando um cliente clica em um produto em um site de comércio eletrônico e o sistema gera recomendações instantâneas de produtos com base nas compras de outros clientes.

A arquitetura orientada a eventos maximiza o potencial das aplicações nativas da nuvem e permite tecnologias de aplicativos poderosas, como análise em tempo real e suporte à decisão. Em geral, substituem a arquitetura tradicional de "solicitação/resposta", em que um aplicativo deve solicitar informações específicas de outro aplicativo e aguardar uma resposta antes de passar para a próxima tarefa.

No entanto, "EDAs" é um termo que inclui vários padrões arquitetônicos, todos os quais podem ser úteis para diferentes propósitos:

No modelo pub/sub [definido por uma dependência de um para muitos entre objetos e uma relação assíncrona desacoplada entre o editor (produtor de eventos) e o consumidor], o editor não precisa saber sobre os assinantes. Ele apenas publica o evento em um canal de evento compartilhado em que os inscritos ouvem e reagem ao evento de forma independente e em tempo real.

Normalmente, um broker de mensagens (roteador) lida com a transmissão de mensagens de eventos entre editores e assinantes. O broker recebe cada mensagem de evento, transforma-a (se necessário), mantém a ordem em relação às outras mensagens, disponibiliza-a para consumo pelos assinantes e, depois, a exclui quando consumida (para que não possa ser consumida novamente).

Os padrões de mensagens de pub/sub são ideais para empresas com grandes bases de código e para transmitir informações para vários consumidores (para sistemas de notificação e feeds de dados em tempo real, por exemplo).

Assim como o pub/sub, o fluxo de eventos separa editores e consumidores para permitir a comunicação assíncrona. Entretanto, no modelo de fluxo de eventos, os consumidores de eventos não precisam de assinaturas para os fluxos; em vez disso, os produtores publicam fluxos de eventos em um log de broker, e os consumidores podem entrar em cada fluxo a qualquer momento e consumir apenas os eventos que desejam consumir (em vez de receber e consumir todos os eventos publicados).

No entanto, ao contrário do pub/sub, os brokers de fluxos de eventos retêm os eventos mesmo depois de os consumidores os receberem.

Como os consumidores podem processar eventos a qualquer momento após sua publicação, os registros de fluxo de eventos são persistentes. Isso significa que eles são mantidas por um período de tempo configurável (de frações de segundo até para sempre) . Os consumidores podem acessar o fluxo a qualquer momento para ler mensagens recentes, processar em lote uma série de mensagens da última vez que acessaram o fluxo ou consultar mensagens relevantes do passado recente.

Tecnologias de fluxos de eventos (como Apache Kafka, Amazon Web Services (AWS) Kinesis e IBM Event Automation também incluem dois modelos: o modelo pull (em que os brokers só enviam dados dos consumidores quando os consumidores indicam que estão abertos a eventos) e o modelo push (onde a lógica de negócios do broker dita quais consumidores recebem eventos).

Os padrões de fluxo de eventos são mais úteis para aplicativos que precisam de atualizações de eventos em tempo real e acesso a eventos passados (sistemas de detecção de fraude para instituições financeiras, por exemplo).

Além dos dois padrões arquitetônicos principais de EDA, três padrões de projeto regem como os eventos são processados quando chegam ao assinante.

• Processamento de eventos simples: em que os consumidores processam eventos exatamente como são recebidos dos editores, acionando ações imediatas.

• Processamento de event streams (ESP): onde as plataformas de fluxo de dados ingerem eventos e criam um pipeline para processadores de fluxo, que, então, processam e transformam o fluxo.
  
  
• Processamento de eventos complexos (CEP): quando os consumidores processam uma série de eventos para identificar tendências e padrões nos dados.

Todos os três padrões de processamento (entre outros) podem ser usados nos padrões arquitetônicos de publicação/assinatura e de fluxo de eventos, mas o ESP é (naturalmente) mais comum no padrão arquitetônico de fluxo de eventos.

As EDAs podem ser úteis para empresas que operam em inúmeros setores, mas são especialmente valiosas para empresas com ambientes de TI grandes e complexos.

As empresas que tentam integrar sistemas executados em diferentes stacks de tecnologia, por exemplo, podem usar as funcionalidades de desacoplamento de arquiteturas baseadas em eventos para manter o sistema de dados de eventos independente e melhorar a interoperabilidade. Corporações multinacionais podem usar uma EDA para coordenar sistemas entre contas e regiões, facilitando a escalabilidade independente de diferentes partes da arquitetura. E para empresas que executam sistemas em que cada um processa diferentes partes de um evento, as funcionalidades de fan-out das EDAs podem enviar eventos para cada consumidor (sem a necessidade de novo código) para processamento paralelo em todo o sistema.

No comércio eletrônico, uma arquitetura baseadas em eventos pode filtrar e encaminhar eventos em tempo real para garantir que eles vão apenas para assinantes interessados em seus dados. Novas compras vão diretamente para os consumidores de processamento de pedidos, e os problemas com pedidos são encaminhados diretamente para os canais de atendimento ao cliente e assim por diante.

As arquiteturas baseadas em eventos estão se tornando essenciais para manter as empresas de hoje atualizadas com o mercado e levá-las para o futuro. De fato, 26% das organizações planejam adotar EDAs para atender às necessidades de negócios, além dos quase 37% de organizações que já o fizeram. ¹ E espera-se que o setor de software de EDA dobre de tamanho, para mais de R$ 16,5 bilhões em receita, até 2027.² 

Milhares de eventos de negócios fluem por todas as partes de uma organização todos os dias, e esses eventos fornecem uma riqueza de informações sobre o que está acontecendo em uma empresa a qualquer momento. No entanto, sem a tecnologia adequada, muitas empresas não conseguem processar e usar esses dados para tomar decisões embasadas sobre seus clientes, produtos ou negócios.

É aí que as plataformas de EDA se tornam inestimáveis, permitindo automação de processos de alta produtividade e baixa latência e fornecendo ferramentas avançadas para uma variedade de casos de uso, incluindo:

As arquiteturas baseadas em eventos colocam os eventos de negócios em ação, permitindo que os usuários detectem situações emergentes, ajam em tempo real, automatizem a tomada de decisão e maximizem o potencial de receita. A EDA também pode ajudar as empresas a sustentar e acelerar o crescimento, ao fornecer:

As EDAs permitem que os sistemas sejam aumentados adicionando mais instâncias de serviços para lidar com cargas de trabalho maiores.

As EDAs permitem que componentes se comuniquem de forma assíncrona; os produtores publicam mensagens de eventos em sua própria programação, sem esperar que os consumidores as recebam (ou mesmo saber se os consumidores as receberam), simplificando a integração e a experiência do usuário.

Os serviços podem ser adicionados, removidos ou modificados de forma independente, facilitando as práticas ágeis de desenvolvimento e implementação.

As EDAs são desacopladas em termos de tempo e sincronização, de modo que produtores e consumidores de eventos interagem por meio de eventos (em vez de chamadas de APIs diretas), o que diminui as dependências e aumenta a resiliência geral do sistema.

A EDA é inerentemente projetada para processamento e resposta em tempo real, permitindo que as equipes respondam de forma mais proativa e facilitando ações e automações mais inteligentes.