Fornecendo eventos em um mundo não-confiável

Exemplos de sistemas event sourcing vêm geralmente de domínios como o e-commerce, os quais são orientados a eventos, com comandos recebidos que geram eventos, e no qual estamos no controle do processo. Mas existem domínios sem processos intrinsecamente confiáveis, em que coletamos eventos a partir de fontes de eventos externos; Lorenzo Nicora recentemente explicou isto na Conferência de Microsserviços µCon London 2017. Os exemplos incluem domínios de logística e transporte assim como IoT e aplicativos móveis que dependem de uma rede não-confiável e podem ser temporariamente desconectados.

Nicora, engenheiro de plataforma da Buildit@wipro digital, observou que nesses domínios não confiáveis acontecem coisas (no mundo externo) que estão fora do nosso controle; os eventos podem estar faltando ou chegar fora de ordem. Apenas reunimos os eventos à medida que chegam e depois tentamos desenhar uma imagem do mundo externo que faça sentido. Essencialmente, temos que largar a distinção entre comandos e eventos que vemos em domínios orientados a processos e começar a aceitar todos os eventos que entram, validá-los e armazená-los o mais rápido possível e, depois disso, aplicar lógica para construir os modelos de leitura. Nicora acredita que este é o mesmo tipo de mudança de paradigma quando se passa de ACID para BASE no mundo do armazenamento de dados. Ele chama essa abordagem de:

Escreva rápido, pense depois.

Neste cenário, a validação de eventos é principalmente uma verificação de segurança para prevenir que eventos forjados ou maliciosos atinjam o sistema, sendo completamente sem estado. Portanto, é possível executar a validação e o armazenamento de eventos em paralelo, o que é ótimo sob a perspectiva de escalabilidade. Usando uma arquitetura de microsserviços, serviços separados podem processar escritas de eventos, criar modelos de leitura e disponibilizar consultas que oferecem uma solução muito escalável, uma vez que cada serviço é escalável independentemente.

As vantagens ao armazenar todos os eventos nesses domínios não-confiáveis ​​incluem a possibilidade de:

• Reordenar eventos - se os eventos chegarem atrasados ​​ou fora de ordem;
• Supor (adivinhar) eventos faltantes;
• Recriar modelos de leitura - ao encontrar inconsistências em modelos ou quando eventos atrasados ​​forem recebidos;
• Atrasar modelos de leitura para dar tempo aos eventos de chegar.

Ao solicitar eventos, o único carimbo de data/hora significativo em um evento é o tempo que foi criado na fonte. O problema é que esse carimbo de data/hora é confiável apenas por dispositivos emissores de eventos, o que significa que não temos uma ordem de eventos global confiável, e não existe uma maneira fácil de contornar isso. Se o pedido entre eventos de diferentes dispositivos é importante, temos que lidar com isso na lógica após os eventos serem armazenados. Nicora também mencionou que, com este design, os modelos de leitura sempre serão atrasados; o quanto estarão atrasados depende do domínio e da implementação.

Nicora concluiu observando que, se estiver trabalhando em um mundo não-confiável com requisitos de escalabilidade altos, esse modelo de consistência de escrita fraca pode ser uma boa solução. Foi enfatizado que ao usá-lo, não devemos tentar dar sentido aos eventos na escrita; em vez disso, devemos nos concentrar na construção de modelos de leitura consistentes.

A próxima conferência de 2018 está prevista para acontecer em 5 e 6 de novembro, em Londres.