Alternativas para consistência eventual em um sistema no padrão CQRS

Abstract

Em sistemas distribuídos, cada vez mais vemos a necessidade de separar fisicamente domínios de negócio diferentes. Porém, sob a perspectiva do usuário final, essa divisão de domínios muitas vezes não existe e os dados passam a ter valor quando associados — tanto em um ambiente transacional quanto analítico. Neste trabalho, partimos de um cenário em que existem vários domínios fisicamente segregados em microsserviços, respeitando o padrão de um banco de dados por serviço. Porém, o produto final para o usuário é um sistema que associa entidades desses múltiplos serviços numa visão única, em forma de listagem e com comandos de escrita sob estes dados. Uma vez que temos os dados separados fisicamente, mas necessitamos mostrá-los juntos em tempo próximo do real, emergem duas opções de padrão descritos na literatura: API compositon (na qual associamos as diversas entidades em memória, a partir de uma aplicação central) e CQRS (na qual segregamos as responsabilidades de escrita e leitura em dois bancos de dados). Nosso objetivo é concentrar esforços em viabilizar a segunda opção (CQRS), avaliando as diferentes abordagens de implementação tendo em vista as limitações impostas pelo nosso caso de uso. Após isso, Apresentamos uma proposta de solução simplificada em relação as abordagens avaliadas, mas com resultados satisfatórios no que tange a garantir consistência eventual sem abrir mão de manutenibilidade. Por último, avaliamos a aplicabilidade dessa solução em um ambiente real e sua viabilidade como uma "porta de entrada"para equipes de desenvolvimento de sistemas experimentar a arquitetura CQRS.

In distributed systems, we increasingly see the need to physically separate different business domains. However, from the end-user’s perspective, this domain division often does not exist, and data becomes valuable when associated — both in a transactional and analytical environment. In this work, we start from a scenario where there are several physically segregated domains in microservices, following the pattern of one database per service. However, the final product for the user is a system that associates entities from these multiple services into a single view, in the form of a listing and with writing commands on these data. Once we have the data physically separated, but need to show them together in near real-time, two pattern options described in the literature emerge: API composition (in which we associate the various entities in memory, from a central application) and CQRS (in which we segregate writing and reading responsibilities into two databases). Our goal is to focus efforts on enabling the second option (CQRS), evaluating different implementation approaches in view of the limitations imposed by our use case. After that, we present a simplified solution proposal compared to the evaluated approaches, but with satisfactory results in terms of ensuring eventual consistency without sacrificing maintainability. Lastly, we discuss its applicability in a real-world environment, being viable as an "entry point" for system development teams to experiment with the CQRS architecture.