Anti-padrões da Arquitetura Orientada a Eventos (EDA): Uma Análise Detalhada (ou não 😁)
Anti-padrões da Arquitetura Orientada a Eventos (EDA): Uma Análise Detalhada
A Arquitetura Orientada a Eventos (EDA) é uma abordagem popular para construir sistemas distribuídos e escaláveis. No entanto, como em qualquer outra arquitetura, existem alguns anti-padrões que podem prejudicar a eficácia e a escalabilidade do sistema. Neste artigo, vamos discutir alguns dos anti-padrões mais comuns da EDA e como evitá-los.
A idéia de lista a baixo não é “cagar regra”, é provocar a racionalização sobre cada um dos itens afim de criar eventos de negócio, que fazem sentido pra atender requisitos de negócio, e não pra atender requisitos técnicos. Como pessoa que coloca a mão no código, super entendo que as vezes precisamos abrir mão do purismo acadêmico e fazer coisas que não são recomendadas. Por isso, avalie os eu caso, e mesmo que aqui eu esteja descrevendo como anti-padrão, se pro seu caso faz sentido, use-o.
Anti padrões:
Eventos excessivamente granulares
Um dos principais benefícios da EDA é a capacidade de desacoplar os componentes do sistema, permitindo que eles evoluam independentemente. No entanto, se os eventos forem muito granulares, o sistema pode se tornar excessivamente complexo e difícil de gerenciar. Isso pode levar a problemas de desempenho e escalabilidade.
Para evitar esse anti-padrão, é importante projetar eventos que sejam significativos para o domínio do negócio e que agreguem valor ao sistema. Os eventos devem ser projetados para serem reutilizáveis e devem ser cuidadosamente equilibrados entre a granularidade e a abstração.
Eventos com muitos dados
Outro anti-padrão comum da EDA é a criação de eventos com muitos dados. Isso pode levar a problemas de desempenho e escalabilidade, pois os eventos grandes podem levar mais tempo para serem processados e consumidos.
Atenção eventos muito grandes, comumente são “eventos genéricos, ou eventos que vazam informações”.
Para evitar esse anti-padrão, é importante projetar eventos que contenham apenas os dados necessários para o processamento e a tomada de decisões. Os eventos devem ser projetados para serem compactos e eficientes, sem sacrificar a integridade dos dados.
Eventos genéricos
Eventos genéricos podem ser considerados um anti-padrão na Arquitetura Orientada a Eventos (EDA), dependendo do contexto em que são usados.
Eventos genéricos são eventos que são projetados para serem reutilizados em vários contextos diferentes. Embora a reutilização de eventos possa ser benéfica em alguns casos, a criação de eventos genéricos pode levar a problemas de desempenho, escalabilidade e complexidade do sistema.
Por exemplo, imagine um sistema de comércio eletrônico que usa um evento genérico de “atualização de estoque” para lidar com todas as atualizações de estoque. Esse evento pode ser usado para atualizar o estoque de um produto quando um pedido é feito, quando um produto é devolvido ou quando um produto é adicionado ao estoque. No entanto, se o evento for muito genérico, pode ser difícil entender o contexto em que ele é usado e pode ser difícil rastrear o fluxo de eventos.
Para evitar esse anti-padrão, é importante projetar eventos que sejam significativos para o domínio do negócio e que agreguem valor ao sistema. Os eventos devem ser projetados para serem específicos para o contexto em que são usados e devem ser cuidadosamente equilibrados entre a granularidade e a abstração. Além disso, é importante implementar um sistema de monitoramento e gerenciamento de eventos que permita rastrear o fluxo de eventos e identificar problemas de desempenho e escalabilidade.
Eventos que vazam informações
“Leaky events” é um termo usado na Arquitetura Orientada a Eventos (EDA) para descrever eventos que vazam informações desnecessárias ou confidenciais para os consumidores de eventos. Esse é um anti-padrão comum que pode levar a problemas de segurança e privacidade.
Por exemplo, imagine um sistema de comércio eletrônico que gera um evento de “pedido recebido” quando um cliente faz um pedido. Se esse evento incluir informações confidenciais, como o número do cartão de crédito do cliente, e esse evento for consumido por outros sistemas, as informações confidenciais podem ser expostas a terceiros não autorizados.
Para evitar esse anti-padrão, é importante projetar eventos que contenham apenas as informações necessárias para o processamento e a tomada de decisões. Os eventos devem ser projetados para serem compactos e eficientes, sem sacrificar a integridade dos dados. Além disso, é importante implementar medidas de segurança, como criptografia e autenticação, para proteger as informações confidenciais.
Falta de controle de versão de eventos
A falta de controle de versão de eventos é outro anti-padrão comum da EDA. Sem um controle de versão adequado, os eventos podem se tornar incompatíveis entre si, o que pode levar a problemas de integração e escalabilidade.
Para evitar esse anti-padrão, é importante projetar eventos com um esquema bem definido e controlar cuidadosamente as alterações no esquema. Os eventos devem ser versionados e os consumidores devem ser capazes de lidar com diferentes versões de eventos.
Falta de monitoramento e gerenciamento de eventos
A falta de monitoramento e gerenciamento de eventos é outro anti-padrão comum da EDA. Sem um monitoramento adequado, pode ser difícil identificar problemas de desempenho e escalabilidade. Sem um gerenciamento adequado, pode ser difícil garantir a integridade e a consistência dos eventos.
Para evitar esse anti-padrão, é importante implementar um sistema de monitoramento e gerenciamento de eventos que permita rastrear o fluxo de eventos e identificar problemas de desempenho e escalabilidade. Os eventos devem ser registrados e auditados para garantir a integridade e a consistência do sistema.
Eventos com baixa qualidade de dados
Eventos com baixa qualidade de dados são outro anti-padrão comum da EDA. Sem dados de alta qualidade, os eventos podem levar a decisões erradas e ações incorretas.
Para evitar esse anti-padrão, é importante projetar eventos que contenham dados precisos e confiáveis. Os dados devem ser validados e verificados antes de serem incluídos em um evento.
Eventos com falta de contexto
Eventos com falta de contexto são outro anti-padrão comum da EDA. Sem contexto adequado, os eventos podem ser difíceis de entender e interpretar.
Para evitar esse anti-padrão, é importante projetar eventos que contenham informações de contexto suficientes para permitir que os consumidores entendam o significado do evento. Os eventos devem ser projetados para serem autoexplicativos e fáceis de entender.
Eventos com falta de validação
Eventos com falta de validação são outro anti-padrão comum da EDA. Sem validação adequada, os eventos podem conter dados incorretos ou incompletos.
Para evitar esse anti-padrão, é importante projetar eventos que contenham dados validados e verificados. Os dados devem ser validados antes de serem incluídos em um evento e os eventos devem ser validados antes de serem consumidos.
Eventos com falta de segurança
Eventos com falta de segurança são outro anti-padrão comum da EDA. Sem segurança adequada, os eventos podem ser vulneráveis a ataques maliciosos e violações de dados.
Para evitar esse anti-padrão, é importante projetar eventos que sejam seguros e protegidos. Os eventos devem ser criptografados e autenticados para garantir a segurança dos dados.
Eventos dependentes um do outro
Eventos dependentes um dos outros podem ser considerados um anti-padrão na Arquitetura Orientada a Eventos (EDA). Esse anti-padrão é conhecido como “Eventos em Cascata” ou “Eventos Dependentes”.
Os eventos em cascata ocorrem quando um evento é gerado em resposta a outro evento, criando uma cadeia de eventos dependentes. Isso pode levar a problemas de desempenho, escalabilidade e complexidade do sistema.
Por exemplo, imagine um sistema de comércio eletrônico que gera um evento de “pedido recebido” quando um cliente faz um pedido. Esse evento pode desencadear uma série de outros eventos, como “verificação de estoque”, “verificação de pagamento” e “envio de confirmação de pedido”. Se esses eventos forem dependentes um do outro, pode haver um atraso significativo no processamento do pedido, o que pode afetar a experiência do cliente.
Para evitar esse anti-padrão, é importante projetar eventos que sejam independentes uns dos outros e que possam ser processados em paralelo. Os eventos devem ser projetados para serem reutilizáveis e devem ser cuidadosamente equilibrados entre a granularidade e a abstração. Além disso, é importante projetar eventos que sejam significativos para o domínio do negócio e que agreguem valor ao sistema.
Eventos sequenciais
Eventos sequenciais ou que dependem de uma sequência não são necessariamente anti-padrões na Arquitetura Orientada a Eventos (EDA). Na verdade, muitos sistemas baseados em eventos dependem de eventos sequenciais para funcionar corretamente.
Por exemplo, imagine um sistema de processamento de pedidos que depende de uma sequência de eventos para processar um pedido. O sistema pode gerar um evento de “pedido recebido” quando um cliente faz um pedido, seguido por um evento de “verificação de estoque”, “verificação de pagamento” e “envio de confirmação de pedido”. Nesse caso, a sequência de eventos é importante para garantir que o pedido seja processado corretamente.
No entanto, é importante ter em mente que a dependência de eventos sequenciais pode levar a problemas de desempenho e escalabilidade se os eventos não forem projetados corretamente. Se os eventos forem muito granulares ou se houver muitos eventos dependentes, o sistema pode se tornar excessivamente complexo e difícil de gerenciar.
Para evitar problemas de desempenho e escalabilidade, é importante projetar eventos que sejam significativos para o domínio do negócio e que agreguem valor ao sistema. Os eventos devem ser projetados para serem reutilizáveis e devem ser cuidadosamente equilibrados entre a granularidade e a abstração. Além disso, é importante implementar um sistema de monitoramento e gerenciamento de eventos que permita rastrear o fluxo de eventos e identificar problemas de desempenho e escalabilidade.
Considerando que não existe garantia de ordenação na entrega das mensagens, mesmo utilizando filas FIFO, esse é um caso a ser considerado de perto em com nível de detalhes, pois pode have problemas intermitentes.
Evento com expectativa
“Events with expectation” é um anti-padrão na Arquitetura Orientada a Eventos (EDA) que ocorre quando um evento é gerado com a expectativa de que outro sistema ou componente irá consumi-lo e agir com base nele. Esse anti-padrão pode levar a problemas de acoplamento e dependência entre sistemas, o que pode afetar a escalabilidade e a flexibilidade do sistema.
Por exemplo, imagine um sistema de comércio eletrônico que gera um evento de “pedido recebido” com a expectativa de que outro sistema irá consumi-lo e processá-lo. Se esse sistema não estiver disponível ou não puder processar o evento, o sistema de comércio eletrônico pode ficar bloqueado e não poderá processar novos pedidos.
Para evitar esse anti-padrão, é importante projetar eventos que sejam independentes e que possam ser consumidos por vários sistemas ou componentes. Os eventos devem ser projetados para serem significativos para o domínio do negócio e que agreguem valor ao sistema. Além disso, é importante implementar um sistema de monitoramento e gerenciamento de eventos que permita rastrear o fluxo de eventos e identificar problemas de desempenho e escalabilidade.
Eventos projetados com uma entidade
“Entity-based events” é um anti-padrão na Arquitetura Orientada a Eventos (EDA) que ocorre quando os eventos são projetados em torno de entidades específicas do sistema, em vez de serem projetados em torno de eventos significativos para o domínio do negócio. Esse anti-padrão pode levar a problemas de acoplamento e dependência entre sistemas, o que pode afetar a escalabilidade e a flexibilidade do sistema.
Por exemplo, imagine um sistema de comércio eletrônico que gera eventos baseados em entidades, como “pedido recebido”, “produto adicionado ao carrinho” e “produto removido do carrinho”. Esses eventos são baseados em entidades específicas do sistema e não são significativos para o domínio do negócio. Isso pode levar a problemas de acoplamento e dependência entre sistemas, o que pode afetar a escalabilidade e a flexibilidade do sistema.
Para evitar esse anti-padrão, é importante projetar eventos que sejam significativos para o domínio do negócio e que agreguem valor ao sistema. Os eventos devem ser projetados em torno de eventos de negócios significativos, como “pedido feito”, “pagamento recebido” e “produto enviado”. Além disso, é importante implementar um sistema de monitoramento e gerenciamento de eventos que permita rastrear o fluxo de eventos e identificar problemas de desempenho e escalabilidade.
Pera ai Creiton, mas e o CDC (Change data capture), ele trabalha com envio de eventos pra viabilizar replicação de dados.
R: É verdade, mas o uso de CDC não implica em estar utilizando uma Arquitetura Orientada a Eventos, mas sim apenas em utilizar uma estratégia de replicação de dados. São conceitos diferentes, usados em contextos diferentes, que pode sim afetar o mesmo o mesmo sistema. Perceba que não fazemos CDC para se comunicar entre dois ou mais sistemas, bem… eu nunca ví😁!
Eventos como um comando
“Events as a command” é um anti-padrão na Arquitetura Orientada a Eventos (EDA) que ocorre quando os eventos são usados como comandos para executar ações em outros sistemas ou componentes. Esse anti-padrão pode levar a problemas de acoplamento e dependência entre sistemas, o que pode afetar a escalabilidade e a flexibilidade do sistema.
Por exemplo, imagine um sistema de comércio eletrônico que gera um evento de “enviar email de confirmação de pedido” com a expectativa de que outro sistema irá consumi-lo e enviar o email. Esse evento é usado como um comando para executar uma ação em outro sistema. Isso pode levar a problemas de acoplamento e dependência entre sistemas, o que pode afetar a escalabilidade e a flexibilidade do sistema.
Para evitar esse anti-padrão, é importante projetar eventos que sejam usados para notificar outros sistemas ou componentes sobre eventos significativos no domínio do negócio, em vez de serem usados como comandos para executar ações em outros sistemas. Os eventos devem ser projetados para serem significativos para o domínio do negócio e que agreguem valor ao sistema. Além disso, é importante implementar um sistema de monitoramento e gerenciamento de eventos que permita rastrear o fluxo de eventos e identificar problemas de desempenho e escalabilidade.
Sei que existem sistemas criados com tópicos de eventos e tópicos de comandos separadamente. Pensando em evento de negócio e acoplamento, fazer uso tópicos de comandos não é uma boa decisão pois obriga um sistema conhecer do outro, quando um dos propósitos dos eventos é permitir que as duas partes não se conheçam, por o ideal é o criador do evento emitir eventos sobre oque ele fez, e quem quiser toma a decisão do que fazer de forma autonoma.
Quando utilizamos tópicos de comando, fazemos com que o produtor saiba que existe um consumidor, levando a modelar as informações dentro do evento de maneira a atender o consumidor, algo que queremos evitar pois gera um acoplamento 1-para-1, oque buscamos com a EDA é 1-para-N.
Clayton, mas então porque existem tópico de comandos e quando uso eles?
R: Basicamente fazemos uso de eventos de comando pra lidar com legados, sistemas pré existentes que já realizam algum processamento e que queremos manter esse processamento no mesmo sistema. Enviar informações pra este sistema processar via API Rest acarreta no colateral de sobrecarga ou recusa por throttling, como maneira de acomodar todas as requisições utilizamos mensageria para enviar as informações pra serem processada através de tópicos ou filas, de maneira a acomodar todas as requisições sem sobrecarregar o sistema legado.
Eventos como chamada de métodos em outro sistema
“Events as method calls” é um anti-padrão na Arquitetura Orientada a Eventos (EDA) que ocorre quando os eventos são usados como chamadas de método para executar ações em outros sistemas ou componentes. Esse anti-padrão pode levar a problemas de acoplamento e dependência entre sistemas, o que pode afetar a escalabilidade e a flexibilidade do sistema.
Por exemplo, imagine um sistema de comércio eletrônico que gera um evento de “atualizar estoque” com a expectativa de que outro sistema irá consumi-lo e atualizar o estoque. Esse evento é usado como uma chamada de método para executar uma ação em outro sistema. Isso pode levar a problemas de acoplamento e dependência entre sistemas, o que pode afetar a escalabilidade e a flexibilidade do sistema.
Para evitar esse anti-padrão, é importante projetar eventos que sejam usados para notificar outros sistemas ou componentes sobre eventos significativos no domínio do negócio, em vez de serem usados como chamadas de método para executar ações em outros sistemas. Os eventos devem ser projetados para serem significativos para o domínio do negócio e que agreguem valor ao sistema. Além disso, é importante implementar um sistema de monitoramento e gerenciamento de eventos que permita rastrear o fluxo de eventos e identificar problemas de desempenho e escalabilidade.
Eventos como meio de chamar métodos, leva naturalmente a criar tópico de comando e outro de resposta. Devemos evitar projetar eventos como substituição de uma API Rest, ou seja devemos evitar projetar evento/tópico que enviam um payload e esperar a resposta em outro evento/tópico. Apesar de funcionar, e super entendo que vai atender ao requisito de negócio, conceitualmente esta não é uma boa prática pois foge da idéia de projetar eventos de negócio. O ideal é criar um tópico de negócio e outro também de negócio, o trabalho é o mesmo, eu sei, mas de um lado temos tópico projeto para atender uma visão técnica, do outro temos tópico projetado para atender uma necessidade de negócio.
Eventos duplicados
Os eventos duplicados são eventos que são gerados várias vezes para a mesma ação ou evento. Esses eventos podem levar a problemas de desempenho e escalabilidade, pois os consumidores de eventos precisam processar muitos eventos duplicados.
Para evitar esse anti-padrão, é importante implementar um sistema de deduplicação de eventos que identifique e remova eventos duplicados antes que sejam consumidos pelos sistemas ou componentes.
Eventos de ciclo infinito
Os eventos de ciclo infinito são eventos que geram outros eventos em um ciclo infinito, levando a um loop infinito de eventos. Esse anti-padrão pode levar a problemas de desempenho e escalabilidade, pois os sistemas ou componentes podem ficar presos em um loop infinito de eventos.
Para evitar esse anti-padrão, é importante projetar eventos que não gerem outros eventos em um ciclo infinito. Os eventos devem ser projetados para serem independentes e não gerar eventos em um ciclo infinito.
Eventos de transação
Os eventos de transação são eventos que são usados para controlar transações em sistemas distribuídos, levando a problemas de desempenho e escalabilidade. Esse anti-padrão pode levar a problemas de desempenho e escalabilidade, pois os sistemas ou componentes precisam esperar pela conclusão da transação antes de continuar o processamento.
Para evitar esse anti-padrão, é importante projetar eventos que não sejam usados para controlar transações em sistemas distribuídos. Os eventos devem ser projetados para serem independentes e não dependerem da conclusão de transações para continuar o processamento.
Eventos de estado
Os eventos de estado são eventos que são usados para controlar o estado do sistema, levando a problemas de acoplamento e dependência entre sistemas. Esse anti-padrão pode levar a problemas de desempenho e escalabilidade, pois os sistemas ou componentes precisam esperar pelo estado do sistema antes de continuar o processamento.
Para evitar esse anti-padrão, é importante projetar eventos que não sejam usados para controlar o estado do sistema. Os eventos devem ser projetados para serem independentes e não dependerem do estado do sistema para continuar o processamento.
Eventos de controle
Os eventos de controle são eventos que são usados para controlar o fluxo de eventos em um sistema, levando a problemas de desempenho e escalabilidade. Esse anti-padrão pode levar a problemas de desempenho e escalabilidade, pois os sistemas ou componentes precisam esperar pelo controle de fluxo antes de continuar o processamento.
Para evitar esse anti-padrão, é importante projetar eventos que não sejam usados para controlar o fluxo de eventos em um sistema. Os eventos devem ser projetados para serem independentes e não dependerem do controle de fluxo para continuar o processamento.
Eventos de latência
Este anti-padrão ocorre quando há um atraso na geração ou processamento de eventos, ou ocorre quando ativamente é criando um atraso (thread.sleep). Isso pode levar a problemas de desempenho e escalabilidade, especialmente em sistemas distribuídos.
Quando um evento é gerado, ele deve ser processado o mais rápido possível para garantir que o sistema possa responder rapidamente às mudanças no ambiente. No entanto, se houver um atraso na geração ou processamento de eventos, isso pode levar a um acúmulo de eventos não processados, o que pode afetar negativamente o desempenho e a escalabilidade do sistema.
Em sistemas distribuídos, a latência pode ser ainda mais problemática, pois a comunicação entre os componentes do sistema pode ser afetada por atrasos na rede ou por problemas de sincronização. Isso pode levar a um aumento na latência de eventos e a um desempenho geral mais lento do sistema.
Para evitar eventos de latência, é importante projetar eventos que sejam gerados e processados de forma eficiente. Isso pode incluir o uso de sistemas de cache para reduzir a latência de acesso a dados e o uso de sistemas de balanceamento de carga para distribuir a carga de trabalho entre os componentes do sistema. Além disso, é importante implementar sistemas de monitoramento para identificar e resolver problemas de latência e garantir que o sistema esteja funcionando de forma eficiente.
Conclusão
A EDA é uma abordagem poderosa para construir sistemas distribuídos e escaláveis. No entanto, como em qualquer outra arquitetura, existem alguns anti-padrões que podem prejudicar a eficácia e a escalabilidade do sistema. Ao projetar sistemas baseados em eventos, é importante evitar esses anti-padrões e projetar eventos que sejam significativos, eficientes e fáceis de gerenciar. Com o planejamento adequado, a EDA pode ser uma abordagem altamente eficaz para construir sistemas distribuídos e escaláveis.
Veja também
