Qual problema queremos resolver?
Bom, como todos vocês já sabem, eu gosto de abordar tecnologia sempre pensando na resolução de um problema, e por esse motivo vamos começar hoje falando um pouquinho dos problemas do nosso dia a dia.
A maior parte do publico que lê estes artigos são pessoas de tecnologia, e familiarizadas com alguns problemas técnicos, mas vamos falar hoje pensando que todos somos usuários do sistema, e não criadores, afinal todos somos mais usuários do que desenvolvedores.
A cada dia que passa nossos sistemas são mais acessados, por mais pessoas e mais processos automáticos, o que traz alguns problemas e dificuldades no dia a dia.
Quando estamos fazendo um projeto para entrega de um sistema, normalmente focamos muito no que chamamos de requisitos funcionais, aquelas regras que fazem o produto acontecer, e acabamos deixando de lado, ou tratando com menos carinho os requisitos não funcionais, ou seja, aqueles requisitos que não são partes do seu negócio, mas que podem acabar com qualquer negociação.
Vamos a um exemplo, imagine que estamos desenvolvendo o software de Netflix, e levantamos um processo a ser construído, dado a consulta do usuário por um título, precisamos buscar em nossas tabelas, verificar se esse titulo existe e mostrar na tela para o usuário, com uma imagem do filme e uma breve descrição.
Podemos notar aqui alguns requisitos funcionais, queremos uma busca e um retorno em tela com alguns detalhes. Até aqui parece fácil, mas veja que em momento algum eu falei sobre tempo de resposta, imagine você como usuário fazendo essa busca, e tendo a resposta após 2 horas. Chega a ser até difícil de imaginar, essa situação não tem nem cabimento, mas precisamos pensar e estruturar nosso sistema para esse tipo de preocupação.
E o que isso tem a ver com o CQRS?
Command Query Responsibility Segregation, é um padrão de arquitetura de sistemas que resolve principalmente o problema de lentidão.
Vamos a um caso de estudo.
Imagine que você possui um sistema de venda de veículos, nesse sistema os vendedores cadastram o veiculo que querem vender, e os clientes filtram e escolhem os carros que estão interessados.
Até aqui tudo certo, agora imagine que vários vendedores e vários clientes estão fazendo esse processo ao mesmo tempo, ou seja, enquanto o vendedor está tentando atualizar os dados de um carro, ou inserir um novo veículo, milhares de clientes estão acessando o sistema consultando na mesma tabela.
Quando isso ocorre, fatalmente teremos uma concorrência de banco de dados, ou seja, ele precisa responder a todas as pesquisas e alterações, e possivelmente não vai dar conta.
Se implementarmos o padrão de CQRS ficamos com um fluxo para gravação e alteração, e outro apartado apenas para leitura, ou seja, caso um vendedor esteja atualizando um registro e o cliente esteja buscando, eles não vão concorrer na tabela.
Conforme a figura, podemos ver que o cliente e o vendedor começam a ter autonomia, e desacoplamento, melhorando a performance geral da aplicação.
Observação
A implementação de CQRS normalmente gera um debate sobre a disponibilidade em tempo real do registro atualizado, ou seja, a pergunta que muitos fazem é. “Nossa mas dessa forma o banco de busca não vai estar 100% atualizado em tempo real”.
Bem a primeira coisa que temos que entender é que nada é 100% em tempo real, quando um dado é inserido em uma tabela tem o tempo de processamento e mais o tempo de gravação na tabela, ou seja, se um dado for inserido no mesmo instante que um usuário estiver buscando, esse dado não será exibido, independente da implementação feita, isso é um fato.
A aplicação do CQRS pode trazer a impressão que essa latência, ou proximidade do tempo real aumente, mas quando estamos falando de sistemas com alto consumo isso não é uma verdade. É fácil notar no dia a dia que a velocidade de consulta do usuário aumenta consideravelmente.
Conclusões
Utilizar o CQRS traz o beneficio da velocidade, mas em compensação aumenta a complexidade de implementação. Precisamos entender bem se o cenário onde estamos trabalhando pede esse tipo de abordagem.
Muitos devem estar se perguntando, mas nossa se estiver na cloud basta aumentar o numero de maquinas e processar. Isso é uma verdade, mas a que custo? Normalmente a subida de bancos para atender a esse cenário acaba por gerar um desperdício financeiro considerável. Por esse motivo eu prefiro a implementação do CQRS antes de buscar a resolução com aumento de processamento.
Deixe uma resposta