Leitura vs escrita: como separar modelo sem complicar cedo demais

O problema

Quase todo sistema começa escrevendo antes de ler em escala.

No início, o mesmo modelo atende:

• criar
• atualizar
• listar
• mostrar detalhe

Só que o produto cresce.

E a leitura começa a pedir:

• filtro demais
• agregação demais
• join demais
• ordenação demais
• tela com dado vindo de muitos lugares

Nessa hora, muita base insiste em espremer tudo do mesmo formato.

O discurso vira:

“é só otimizar a query”

Às vezes é mesmo.

Mas às vezes o problema é que leitura e escrita já estão pedindo formas diferentes.

Modelo mental

Escrita normalmente quer:

• consistência
• validação
• regra
• transição de estado

Leitura normalmente quer:

• projeção
• filtro
• ordenação
• composição para tela
• velocidade e previsibilidade

Essas pressões não são iguais.

Por isso, o mesmo modelo não precisa servir os dois lados para sempre.

Isso não significa virar CQRS cedo

Muita gente escuta “separar leitura e escrita” e imagina:

• dois bancos
• eventos para tudo
• projeção para cada tela
• complexidade dobrada

Não precisa começar assim.

Separação pode nascer de forma bem mais pragmática:

• query objects
• views materializadas
• tabela de projeção
• read model específico para uma tela crítica

O ponto é aceitar a diferença de pressão.

Exemplo simples

Imagine um sistema de pedidos.

Para escrita, você quer algo como:

• pedido
• itens
• pagamento
• transições válidas de status

Para leitura, a tela de operação quer:

• cliente
• status atual
• atraso
• último evento
• valor total
• risco
• filtros por período e canal

Se você tentar tirar isso sempre do mesmo modelo transacional, pode acabar com:

• query enorme
• ORM sofrendo
• N+1
• endpoint imprevisível
• tela lenta

Talvez a solução não seja só “otimizar mais”.

Talvez seja criar uma projeção de leitura melhor para esse uso.

Quando a separação começa a fazer sentido

Sinais comuns:

• o mesmo endpoint vive acumulando join e condição
• a leitura para dashboard ou listagem ficou bem diferente da escrita
• filtros e ordenações já não combinam bem com o modelo transacional
• o time cria cache em cima de query ruim para esconder desconforto estrutural

Nesses casos, separar leitura de escrita pode simplificar mais do que complicar.

Quando ainda é cedo

Também existe overengineering aqui.

Se a dor ainda é pequena, talvez baste:

• ajustar índice
• melhorar consulta
• evitar N+1
• separar serviço de leitura sem criar projeção nova

Nem todo problema de query é justificativa para discurso de CQRS.

O ponto é perceber padrão recorrente, não reagir a um incidente isolado.

Como um senior pensa

Quem tem mais repertório costuma perguntar:

• essa dor é de modelagem de leitura ou de implementação ruim?
• estamos tentando servir muitos usos diferentes com uma única estrutura?
• vale criar projeção agora ou só melhorar consulta?
• qual parte da complexidade estamos comprando e por quê?

Esse olhar evita dois erros:

• complicar cedo demais
• simplificar por tempo demais

Ângulo de entrevista

Esse tema aparece em system design, backend e performance.

O entrevistador quer ver se você entende:

• que leitura e escrita têm pressões diferentes
• quando separar ajuda de verdade
• como começar pequeno sem teatralizar CQRS
• como justificar o trade-off entre simplicidade e escala

Resposta forte parece algo como:

“Eu não abriria CQRS completo por padrão, mas separaria o modelo de leitura quando os usos de consulta começarem a pedir projeções, filtros e composição que o modelo transacional não atende bem sem virar query frágil demais.”

Takeaway direto

Separar leitura de escrita não é sinal de arquitetura sofisticada.

É sinal de que você percebeu que confirmar estado e servir consulta grande são problemas parecidos só no nome.