CQRS: talvez você não precise dele. E está tudo bem.

CQRS aparece em conversa de arquitetura com uma frequência que não condiz com quantos projetos realmente precisam da versão mais elaborada dele. Vale separar o que o padrão promete na forma simples do que ele exige na forma complexa, porque são compromissos bem diferentes.

O que CQRS realmente propõe

Command Query Responsibility Segregation separa operações que alteram estado, comandos, de operações que apenas leem estado, queries, tratando as duas como responsabilidades distintas em vez de misturá-las no mesmo modelo e no mesmo caminho de código. A motivação original é que leitura e escrita frequentemente têm necessidades diferentes: escrita se importa com regra de negócio e consistência, leitura se importa com formato de apresentação e velocidade.

A versão simples: mesmo banco, modelos separados

Na forma mais simples, CQRS não exige banco de dados separado nenhum. Comando e query continuam apontando para o mesmo banco, a diferença é organizacional: um caminho de código dedicado a alterar estado, respeitando toda regra de negócio envolvida, e outro caminho dedicado só a consultar, muitas vezes usando uma projeção mais direta, sem passar pelas mesmas regras e validações do lado de escrita.

public record CriarPedidoCommand(int ClienteId, List<ItemPedido> Itens);

public record ObterPedidoQuery(int PedidoId);

Bibliotecas como MediatR ajudam a formalizar essa separação, roteando cada comando ou query para o handler correspondente, sem exigir infraestrutura adicional além do que o projeto já usa.

Essa versão simples resolve um problema real, código de leitura e escrita que cresceu misturado até ficar difícil de alterar um sem afetar o outro, com um custo de complexidade relativamente baixo.

A versão complexa: bancos heterogêneos e consistência eventual

A versão que costuma gerar arrependimento é outra: banco separado para escrita e para leitura, sincronizados via evento, com o lado de leitura eventualmente consistente em relação ao lado de escrita. Essa arquitetura resolve problemas de escala que poucos projetos realmente enfrentam, ao custo de uma complexidade operacional considerável: infraestrutura de mensageria para propagar mudança, tolerância da aplicação e do usuário a uma janela de inconsistência entre escrita e leitura, e superfície de falha bem maior, porque agora existem dois sistemas de armazenamento para manter sincronizados em vez de um.

O custo que passa despercebido até aparecer

O problema não é a complexidade em si, é ela aparecer depois que a decisão já está tomada. Debugar um caso em que a leitura mostra dado desatualizado, porque o evento de sincronização ainda não propagou, exige entender toda a cadeia de eventos entre escrita e leitura, não só o código que falhou. Esse tipo de investigação é ordens de grandeza mais trabalhoso do que depurar uma consulta direta contra o mesmo banco onde a escrita aconteceu.

Quando cada versão faz sentido

CQRS simples, no mesmo banco, compensa quando o modelo de leitura e o de escrita já divergiram o suficiente para justificar caminhos de código separados, mesmo sem qualquer necessidade de escala. CQRS com bancos heterogêneos só se justifica quando existe um problema real de escala ou de característica de acesso a dado que um único banco, com um único modelo, não consegue atender bem, geralmente volume de leitura muito maior que o de escrita, com padrão de consulta que se beneficia de um formato de armazenamento diferente do usado na escrita.

Está tudo bem não precisar da versão complexa

Boa parte dos projetos nunca vai encostar no cenário que justificaria bancos heterogêneos e consistência eventual, e isso não é sinal de arquitetura menos sofisticada. CQRS na forma simples já entrega o benefício de separação de responsabilidade sem herdar o custo operacional da forma mais elaborada. Adotar a versão complexa só porque ela aparece em todo artigo sobre o padrão, sem o problema de escala que a justificaria, troca um código organizado por um sistema distribuído para resolver um problema que talvez nunca existisse.