Quando estamos fazendo o design de um sistema distribuído, eventualmente baseado em microservices, e ao considerar utilizar uma arquitetura orientada a eventos, podemos escolher dentre vários modelos e tecnologias disponíveis. Descrevendo diferentes estilos de arquiteturas orientadas a eventos, David Dawson, em recente publicação, alega que requisitos não funcionais são o fator principal na escolha de como implementar uma arquitetura deste tipo.
Dawson, um arquiteto de sistemas freelancer, simplesmente define uma Arquitetura Orientada a Eventos como uma arquitetura de software baseada em eventos, e devido ao fato de os eventos serem parte de um modelo de dados, tornam-se também uma Arquitetura de Dados. Ele enfatiza que a arquitetura não é apenas um conjunto de tecnologias ou um modelo específico de como os serviços interagem.
Um modelo simples e bem estabelecido é o "Staged Event-Driven Architecture (SEDA)", que é essencialmente um processo baseado em fluxo de tarefas cujos componentes geram eventos como resultado de seu processamento, dessa forma, guiando o processo como um todo. Eventos são usualmente transportados usando algum tipo de barramento para processamento de mensagens. Dawson observa que um problema importante a respeito desse modelo é que os eventos têm vida curta e, portanto, podem se perder durante o transporte ou se algum componente está inoperante no momento de seu processamento. Então, ao invés de um sistema que apresenta "consistência eventual", tem-se o que ele chama de "consistência esperada",ou esperançosa! do inglês "hopeful consistency". Enquanto tudo funcionar. o sistema será consistente. Entretanto, quando ele falha, terminamos com um sistema inconsistente e temos que recuperá-lo manualmente para devolvê-lo ao estado consistente. Dawson chama esta solução de "micro-serviços orientados a entidades" e aconselha fortemente que esse tipo de arquitetura não seja utilizado.
A fim de reconstruir o estado consistente, a melhor solução, na opinião de Dawson, é aceitar que eventos são dados e armazenar a cadeia de eventos. Assim, será possível repetir a cadeia a qualquer momento para restaurar o estado e ter um sistema realmente "eventualmente consistente". Podemos também obter outros benefícios, incluindo a possibilidade de ter múltiplas visões da mesma cadeia de eventos.
Na experiência de Dawson, armazenar cadeias de eventos é usualmente chamado de "event sourcing", que podemos chamar de "suprimento por eventos", mas ele acredita que isso é incorreto, uma vez que não se trata de recriar o estado de uma única entidade, trata-se de criar visões de um conjunto infinito de entidades. Sendo assim, ele prefere chamar esse estilo de arquitetura de "stream processing", ou seja, literalmente, processamento da cadeia de eventos. Essa é uma arquitetura muito adequada para ser usada com o Apache Kafka. O cliente Kafka lê da cadeia os eventos em ordem, mas pode também repetir a leitura do início ou de qualquer evento da cadeia, se necessário.
Um agregado é, no jargão DDD (Domain-Driven design), um conjunto de entidades dentro de uma fronteira consistente. Gerando eventos e os armazenando para todas as alterações de um agregado e criando o estado do mesmo agregado repetindo os mesmos eventos, temos um "event sourced aggregate root", que pode-se definir como "agregado original suprido por evento". Dawson define isso como o verdadeiro "suprimento por eventos" . Ele ressalta a importância de se ter uma única cadeia de eventos para reconstruir o agregado. Para outras necessidades, tal como criação de visões, deve-se criar cadeias separadas.
A fim de apoiá-lo na construção de sistemas baseados em um modelo de arquitetura orientada para eventos, Dawson criou a Muon Stack, que é um conjunto de bibliotecas e serviços para a construção de sistemas distribuídos orientados a mensagens e eventos. A biblioteca inclui, dentre outras coisas, uma API cliente para para processamento de cadeias de eventos e o Photon, uma solução de armazenamento de eventos. Atualmente ele está trabalhando para portar essa solução para o Apache Kafka.