System Design/04 - Cloud Design Patterns/Design & Implementation2 min
CQRS
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Command Query Responsibility Segregation: separar o modelo de escrita (comandos) do modelo de leitura (consultas).
comando → modelo de escrita → banco de escrita
↓ projeta
consulta ← modelo de leitura ← banco de leitura
A justificativa é que os dois têm requisitos opostos: a escrita precisa de normalização, validação e transação; a leitura precisa de desnormalização e formato pronto para a tela.
Níveis de adoção
| Nível | O que separa |
|---|---|
| Leve | Apenas as classes/modelos, mesmo banco |
| Médio | Tabelas de leitura desnormalizadas (Materialized View) |
| Completo | Bancos diferentes, sincronizados por evento |
Trade-offs
O ganho é poder otimizar cada lado independentemente: escala de leitura separada da de escrita, e um modelo de leitura que responde a consulta da tela sem junção nenhuma.
O custo cresce muito rápido com o nível de adoção. Na forma completa:
Consistência eventual. O usuário grava e não vê o resultado imediatamente — o modo de falha mais visível e o que mais gera bug reportado. As mitigações são conhecidas (ler do modelo de escrita logo após uma escrita, ou devolver o resultado no próprio comando) e adicionam casos especiais.
Dobra de artefatos. Dois modelos, duas persistências, um mecanismo de projeção — mais código, mais deploy, mais coisas para monitorar.
Projeção pode quebrar ou atrasar. Alguém precisa detectar e reconstruir.
Por isso a recomendação consolidada: CQRS não é padrão padrão. Aplique-o a um subdomínio específico, quando a assimetria entre leitura e escrita for medida e grande — não ao sistema inteiro por princípio.
Ele combina naturalmente com Event Sourcing (os eventos alimentam as projeções), e os dois juntos multiplicam tanto o benefício quanto a complexidade.
Exemplo prático
Um e-commerce com razão leitura:escrita de 100:1 no catálogo.
Escrita: tabelas normalizadas de produto, categoria, estoque e preço, com transação e validação.
Leitura: um documento por produto no Elasticsearch, com tudo embutido — nome, categoria, preço, disponibilidade, avaliações. A busca é uma consulta, sem junção.
Um evento de alteração de preço atualiza a projeção em ~1 segundo. Durante esse segundo, a vitrine mostra o preço antigo — aceitável para catálogo.
O checkout, porém, lê do modelo de escrita. É a mesma aplicação escolhendo consistência forte onde ela importa e eventual onde não importa — e é essa granularidade que torna o padrão útil em vez de dogmático.
Relacionado
Parte de Design & Implementation · roadmap.sh/system-design