Eventos: Somente ID ou Dados completos?

Contexto

Eventos no desenvolvimento de software são fatos que ocorreram dentro um sistema e normalmente são publicados em um local para que outras aplicações possam consumir e reagir de acordo com a sua necessidade. Por exemplo: "Pedido criado", "Pagamento confirmado", "Estoque atualizado", entre outros.

Eventos são amplamente utilizados, especialmente em arquiteturas baseadas em microsserviços. No entanto, ao implementá-los, pode surgir a dúvida sobre quais dados devem ser enviados na mensagem: Apenas o identificador ou os dados completos? Para tentar ajudar com essa questão, a seguir estão algumas considerações sobre essas abordagens, com suas respectivas vantagens e desvantagens.

Somente ID

Uma das opções é enviar na mensagem, somente o identificador da entidade relacionada ao evento. Se para o consumidor interessar apenas a informação que o evento ocorreu, esta mensagem é o suficiente, porém, é comum que o consumidor necessite de informações adicionais. Nesse caso, ele precisaria usar o identificador contido na mensagem para solicitar ao serviço responsável os dados completos da entidade.

Por exemplo, um serviço de compras envia um evento de "Compra efetuada", contendo apenas o ID da compra. O serviço de estoque recebe a notificação que a compra ocorreu, porém, precisa dos detalhes da compra para poder atualizar a informação no estoque, portanto, o serviço de estoque utiliza o ID recebido na mensagem para fazer uma requisição para o serviço de compras e obter os detalhes adicionais que precisa.

Vantagens

A principal vantagem dessa abordagem é a possibilidade de controlar qual serviço vai ter acesso a determinadas informações. Pode existir um cenário onde várias aplicações consomem a informação que o evento ocorreu, mas não necessariamente todas devem ter acesso a todos os dados. Esse controle seria feito no momento que os consumidores requisitassem os detalhes.

Desvantagens

A desvantagem deste modelo é o acoplamento, pois, os consumidores normalmente precisam saber da existência do serviço de origem e como buscar as demais informações. Além do que, dependendo da quantidade de consumidores requisitando informações, pode gerar um aumento excessivo de requests onerando a aplicação geradora do evento.

Vantagens

Diferente do evento apenas com identificador, os serviços consumidores não precisam buscar os detalhes do evento no serviço de origem. Não precisam sequer saber de sua existência, pois, todos os dados necessários estarão presentes na mensagem.

Como os dados do evento estarão completos, possibilita aplicar auditoria ou padrões, como: Event Sourcing.

Event Sourcing: é um padrão onde se armazena o estado de uma entidade durante seu ciclo de vida, permitindo reconstrui-la em um determinado ponto da linha do tempo. Veja mais no link: Event Sourcing, Martin Fowler.

Desvantagens

Pode estar trafegando muitas informações pela rede, sendo que, muitas vezes, parte desses dados podem ser irrelevantes para a maioria dos consumidores. Dependendo da quantidade de informações pode esbarrar, inclusive, nos limites dos brokers de mensagens, como Kafka ou RabbitMQ, que apesar de atualmente serem bem generosos, esses limites existem e devem sempre ser considerados.

Conclusão

Como praticamente tudo na nossa área, a adoção de uma estratégia ou outra deve depender de cada situação. O importante é entender as possibilidades, vantagens e desvantagens de cada uma e qual é mais adequada para cada circunstância. Apesar de, na maioria das vezes acabar optando por enviar os detalhes completos do evento, em minha experiência profissional já apliquei os dois modelos e acredito que ambos tem espaço para utilização.

Não podemos deixar de considerar, também, o uso de um modelo híbrido, onde se envia os principais detalhes do evento, mas não necessariamente todos. Essa abordagem pode ser muito útil e combinar os benefícios das duas estratégias.

Referências

• Newman, S. (2021). Building Microservices: Designing Fine-Grained Systems (2nd ed.). O'Reilly Media.