A arquitetura orientada a eventos (EDA) é uma forma de construir software em que as partes de um sistema comunicam anunciando que algo aconteceu, em vez de se chamarem diretamente umas às outras. Um componente publica um evento, como “fatura paga” ou “contrato assinado.” Qualquer outro componente interessado reage a esse evento. Nenhum dos lados precisa de saber que o outro existe.

Para uma empresa SaaS, isto importa muito para além da engenharia. A mesma ideia está por trás de transferências limpas entre o CRM e as finanças, de uma automação fiável e de agentes de IA que atuam sobre dados atuais. Este guia explica como funciona a EDA, em que difere um barramento de eventos de uma fila, como evitar as falhas comuns e onde ela se aplica e não se aplica.

Em resumo

Índice

O que é a arquitetura orientada a eventos

A orientação de arquitetura da Microsoft descreve o estilo como produtores de eventos que geram um fluxo de eventos, consumidores de eventos que os escutam e canais de eventos que transportam os eventos de uns para os outros. Esse modelo de três partes é a ideia toda. Tudo o resto é pormenor sobre a fiabilidade e a rapidez com que o canal funciona.

O contraste é com o modelo pedido/resposta. Num desenho de pedido/resposta, o seu serviço de faturação chama o CRM e espera por uma resposta. Se o CRM estiver lento ou indisponível, a faturação fica bloqueada. Num desenho orientado a eventos, a faturação publica “pagamento recebido” e segue em frente. O CRM, o relatório de receitas e o painel de sucesso do cliente recolhem o evento quando estiverem prontos.

Daqui decorrem duas propriedades:

O que conta como evento

Um evento é a afirmação de um facto no passado. A Red Hat descreve-o como um registo imutável de que algo aconteceu, muitas vezes com um carimbo de data/hora que preserva a ordem relativamente ao sistema que o produziu. Um evento não se edita depois de criado. Se algo mudar, um novo evento regista a alteração.

A AWS refere que os eventos podem ser uma alteração de estado ou uma atualização, e podem transportar o estado ou ser identificadores. Dois exemplos:

Estilo Exemplo O que o consumidor recebe
Evento que transporta o estado Subscrição atualizada, com plano, preço, data de entrada em vigor e ID da conta Tudo o que é necessário para agir sem uma segunda consulta
Evento como identificador Encomenda expedida, apenas com o ID da encomenda Um sinal. O consumidor obtém os detalhes no sistema de origem

O primeiro é cómodo, mas acopla os consumidores à forma do evento. O segundo mantém os eventos pequenos, mas envia os consumidores de volta ao sistema de origem, o que levanta a questão de qual é o sistema de referência. Voltamos a este ponto abaixo, porque é aí que a maioria das stacks de operações SaaS tem dificuldades.

Um comando não é um evento. “Enviar a fatura” é uma instrução dirigida a um destinatário específico. “Fatura enviada” é um facto a que qualquer um pode reagir. Misturar os dois é um erro de desenho comum e reconstrói, de forma discreta, o acoplamento forte que se pretendia eliminar.

Como funciona um sistema orientado a eventos, passo a passo

A documentação da Google Cloud descreve o fluxo: os produtores geram eventos, um router ou broker recebe-os e filtra-os e, depois, distribui-os pelos consumidores com base em subscrições ou triggers. Na prática:

  1. Algo acontece. Um negócio passa para «Closed Won» no CRM.
  2. O produtor publica um evento. O evento enuncia o facto e o registo a que diz respeito.
  3. O broker encaminha-o. Filtra o evento e entrega-o a todos os subscritores.
  4. Os consumidores reagem de forma independente. A Finance cria um rascunho de fatura. O Customer Success abre um plano de onboarding. Um processo de provisionamento prepara os acessos.
  5. Cada consumidor confirma a receção. O broker sabe que o evento foi tratado e pode voltar a tentar se não tiver sido.

A IBM apresenta o mesmo padrão como publicação, captura, processamento e armazenamento de eventos e salienta que o valor de um evento pode mudar ao longo do tempo. Um evento de «novo lead» merece ação em minutos. Um ano depois, serve sobretudo para análise.

Arquitetura orientada a eventos e microsserviços

Muitas vezes tratam-se estes conceitos como se fossem o mesmo. Não são. Os microsserviços descrevem como se divide uma aplicação em serviços pequenos, implementados de forma independente. A EDA descreve como esses serviços comunicam. Pode haver microsserviços que se chamam uns aos outros de forma síncrona, e pode haver um monólito que publica eventos internamente.

Os dois funcionam bem em conjunto. A orientação da Google refere que os microsserviços podem reagir de forma assíncrona a eventos e só precisam de conhecer o formato do evento, não a lógica de negócio uns dos outros. Esse formato partilhado é o contrato. Tudo o que está por trás pode mudar.

A documentação da Microsoft descreve o padrão típico como microsserviços que publicam um evento quando acontece algo relevante, com outros microsserviços a subscrevê-lo.

Barramento de eventos vs. fila vs. fluxo

Estes três termos são os que geram mais confusão, e a escolha altera o comportamento do seu sistema.

Event bus (publish/subscribe). Um event bus é um mecanismo em que os publicadores anunciam eventos e os subscritores os recebem. A Microsoft explica que pode ser implementado sobre uma infraestrutura de mensagens, como uma fila ou um service bus que suporte publish/subscribe assíncrono. Assim, uma fila pode ser um dos blocos de construção de um bus. O bus é a intenção. A fila é uma forma de a concretizar.

Fila. Uma fila guarda mensagens até um worker as recolher. Normalmente, cada mensagem é tratada por um único consumidor. As filas são a ferramenta certa para distribuir trabalho por vários workers e absorver picos de carga. A orientação de integração do Azure indica colocar mensagens em fila quando um back end está indisponível como um dos motivos para usar um broker.

Event stream. O Azure distingue o publish/subscribe do streaming. No publish/subscribe, depois de um evento ser recebido, não fica guardado num registo durável, pelo que os novos subscritores não veem os eventos passados. No streaming, os eventos são escritos num registo durável e estritamente ordenado dentro de uma partição, e os clientes leem a partir do registo e podem juntar-se a qualquer momento e reproduzir eventos.

Fila Bus publish/subscribe Event stream
Entrega Um consumidor por mensagem Todos os subscritores Qualquer leitor, a partir de qualquer ponto
Eventos passados Removidos após o processamento Não disponíveis para novos subscritores Guardados e reproduzíveis
Utilização típica Distribuição de trabalho, buffering Notificação de vários sistemas Histórico, análise, reconstrução de estado

Uma regra prática: se precisa que vários sistemas reajam ao mesmo facto, use publish/subscribe. Se precisa que um worker execute uma tarefa, use uma fila. Se precisa de histórico ou da capacidade de reconstruir um sistema a jusante, use um stream. A Red Hat acrescenta que não existe uma solução única para todos os casos, por isso escolha a tecnologia consoante o tipo de evento.

O Kafka é uma arquitetura orientada a eventos?

Não. O Kafka é uma tecnologia que pode usar para construir uma. A documentação do Apache Kafka descreve-o como uma plataforma de event streaming: captura eventos em tempo real, armazena-os de forma durável, processa-os e encaminha-os para outros sistemas. Isso faz dele um event stream, na tabela acima.

Uma arquitetura é um conjunto de decisões de design: quais são os eventos, quem é o seu responsável, como se isolam os consumidores, o que acontece em caso de falha. Pode tomar essas decisões e executá-las num bus gerido na cloud, num serviço de filas ou no Kafka. Também pode executar o Kafka e continuar a ter um sistema fortemente acoplado, se cada serviço depender dos eventos internos de outro serviço. Escolha a ferramenta depois de definir os eventos e o volume que realmente espera.

Integração e automação orientadas a eventos

É aqui que a EDA se torna relevante para os responsáveis de operações, e não apenas para os engenheiros.

Integração

A maioria das empresas SaaS liga os dados de CRM, faturação, suporte e produto através de sincronizações ponto a ponto. Cada nova ferramenta acrescenta mais uma ligação para manter. O Azure recomenda comunicação assíncrona através de um message broker em vez de chamadas síncronas diretas, por quatro razões que enumera: desacoplar aplicações, difundir para vários consumidores, acompanhar com fiabilidade fluxos de trabalho de longa duração e colocar mensagens em fila quando um back end está indisponível.

A vantagem aparece quando se acrescenta um sistema. Com um serviço publish/subscribe, é possível adicionar novos subscritores sem atualizar o emissor. Adicionar uma nova ferramenta de análise não exige qualquer alteração ao seu CRM.

Automação

A automação orientada a eventos significa que um processo de negócio arranca porque algo aconteceu, e não porque alguém clicou num botão ou porque correu uma tarefa noturna. O guia de flows da ServiceNow propõe um método prático: identificar o trigger, planear a lógica, selecionar as ações e identificar a lógica reutilizável. Recomenda também manter os flows focados e usar um verbo por ação.

Quando um processo abrange vários serviços, a Microsoft refere que os sistemas orientados a eventos usam habitualmente padrões de coreografia e de orquestração de sagas para coordenar o fluxo. Na coreografia, cada serviço reage a eventos e emite os seus próprios. Na orquestração, um coordenador indica a cada passo o que fazer e acompanha o processo completo. Num primeiro projeto, um fluxo orquestrado costuma ser mais fácil de ler e de auditar.

Um exemplo simples de SaaS:

Boas práticas e desafios comuns

A Azure enumera os principais desafios: consistência eventual, tratamento assíncrono de erros, perda de dados, observabilidade e testes, eventos em excesso ou demasiado consolidados, e evolução de esquemas. Cada um tem uma prática correspondente.

  1. Planeie a consistência eventual. Os sistemas vão divergir por breves momentos. Decida qual é o sistema de referência para cada facto e deixe os restantes segui-lo.
  2. Adicione um tratador de erros dedicado. Os eventos que falham precisam de um destino e de alguém que os analise.
  3. Conserve os eventos até a receção ser confirmada. Isto protege contra a perda de dados quando um consumidor está em baixo.
  4. Utilize IDs de correlação. Um único ID transportado por todos os passos permite rastrear uma única ação de um cliente através dos sistemas.
  5. Equilibre a granularidade dos eventos. Um evento por cada alteração de campo cria ruído. Um único evento gigante para tudo volta a criar acoplamento.
  6. Versione os esquemas desde cedo. Os formatos dos eventos vão mudar. Decida como, antes de ter vinte consumidores.

A estes acrescentaríamos três hábitos operacionais: nomear os eventos no passado, atribuir um único responsável a cada tipo de evento e documentar quais os consumidores que dependem dele.

Onde o desenho orientado a eventos não se aplica

A EDA não é a resposta para todos os problemas. Seja explícito quanto aos limites antes de se comprometer:

A mesma lógica aplica-se à IA. Um assistente de IA que lê e atua nos seus sistemas é consumidor e produtor de eventos. Se ler dados inconsistentes ou agir sem um limite de permissões, tem uma forma mais rápida de cometer erros.

Onde isto encontra os agentes de IA e a conformidade

Os agentes de IA que obtêm dados (perguntar, reportar, consultar) e enviam dados (atualizar um registo, desencadear um processo, atribuir acessos) comportam-se como participantes num sistema orientado a eventos. Precisam de uma fonte fiável para ler, de um conjunto claro de ações permitidas, de aprovação para os passos sensíveis e de um registo do que fizeram. Um registo de eventos é o local natural para esse registo.

Operador a rever o registo de eventos de um agente de IA

Para as empresas europeias, o GDPR, a NIS2 e o EU AI Act afetam todos a forma como estes sistemas são concebidos. Em termos gerais, dizem respeito aos dados pessoais que circulam nos eventos, à forma como a segurança e a gestão de incidentes são organizadas e à forma como os sistemas de IA são governados e documentados. Trate-os como requisitos de conceção desde o início e peça aconselhamento jurídico a um advogado sobre a sua aplicação ao seu caso concreto. Nenhuma escolha de arquitetura, por si só, torna um sistema conforme.

A nossa perspetiva

A maioria das empresas SaaS com quem falamos não tem um problema de eventos. Tem um problema de responsabilidade. Várias equipas usam IA, várias ferramentas guardam uma versão do cliente e ninguém é responsável por determinar qual é a correta.

É por isso que trabalhamos por uma ordem fixa. Primeiro, a data foundation: os dados de CRM e de finanças como fonte de verdade acordada. Depois, a camada de IA, que liga esses dados ao assistente que a sua equipa já utiliza. Por fim, os agentes departamentais para Finanças, Vendas e Customer Success. Os eventos são úteis nas três camadas, mas só ajudam quando os factos que transportam estão acordados.

Também adotamos um processo de cada vez, começando pelo mais dispendioso. Um processo de renovação ou a passagem de fatura a cobrança é um melhor primeiro projeto orientado a eventos do que uma reconstrução à escala da empresa. Vê o resultado, as suas pessoas aprendem o padrão e o processo seguinte fica mais barato.

Como gerimos as operações e também concebemos sistemas, preocupamo-nos com as partes pouco glamorosas: permissões, aprovações, registos de auditoria e uma entrega em que o código, a documentação e a infraestrutura ficam consigo.

Claus Nielsen

Como começar na sua própria empresa

Não precisa de escolher primeiro um broker. Comece por estas perguntas:

  1. Que processo lhe custa mais em trabalho manual, atrasos ou erros?
  2. Quais são os dois ou três eventos que o iniciam (por exemplo, negócio fechado, fatura em atraso, renovação a aproximar-se)?
  3. Que sistema é a fonte de verdade dos dados nesses eventos?
  4. Quem é responsável por cada definição de evento?
  5. Que passos exigem aprovação humana?

Se não souber responder à terceira pergunta, a data foundation vem primeiro. Se souber, um pequeno piloto num processo mostrar-lhe-á se uma abordagem orientada a eventos compensa.

Como podemos ajudar

Se a sua equipa utiliza IA mas ninguém é responsável por ela, podemos ajudá-lo a decidir onde compensa e a construí-la pela ordem certa. O nosso AI Readiness Assessment está disponível a partir de €4,500 e analisa os seus dados, sistemas e processos antes de qualquer construção. Se pretender uma liderança contínua, o contrato de Fractional Chief AI Officer começa em €1,500 por mês.

As implementações são cobradas a 30% de uma poupança do primeiro ano medida e comprovada, ou a um preço fixo acordado antes de o trabalho começar. Pode também marcar uma chamada de descoberta gratuita de 30 minutos através do nosso site. Os nossos agentes de IA para Finanças, Vendas e Customer Success mostram como é a camada departamental quando a base está implementada.

FAQ

O que é a arquitetura orientada a eventos em termos simples?

É um desenho em que os componentes de software anunciam que algo aconteceu e outros componentes reagem. Quem envia não sabe quem está a ouvir. Isto permite acrescentar ou alterar sistemas sem reescrever os que produzem os eventos.

Qual é a diferença entre um event bus e uma fila de mensagens?

Uma fila entrega normalmente cada mensagem a um único worker. Um event bus entrega cada evento a todos os subscritores. Um bus pode ser construído sobre infraestrutura de filas, pelo que a diferença está na intenção e no padrão de entrega, nem sempre no produto.

A arquitetura orientada a eventos é o mesmo que microsserviços?

Não. Os microsserviços dizem respeito à forma como uma aplicação é dividida em serviços. A arquitetura orientada a eventos diz respeito à forma como as partes comunicam. Costumam ser usados em conjunto, mas cada um pode existir sem o outro.

Quando deve uma empresa de SaaS utilizar automação orientada a eventos?

Utilize-a quando um processo de negócio deve ser iniciado por um facto, como um negócio fechado ou uma renovação a aproximar-se, e várias equipas ou sistemas precisam de reagir. Comece por um processo dispendioso e certifique-se de que os dados de origem ficam primeiro acordados.

Fontes