Read model interno para relatório sem vazar consulta pesada para o fluxo transacional

O problema

Relatório costuma nascer como “só mais uma query”.

Depois vira:

• join demais
• filtro demais
• agregação demais
• exportação gigante
• leitura histórica longa

Se isso continua batendo no mesmo desenho do fluxo transacional, a arquitetura começa a cobrar:

• CPU
• lock
• latência
• índice estranho demais
• schema distorcido para agradar relatório

Modelo mental

Read model interno para relatório não é luxo.

É uma forma de separar duas perguntas diferentes:

• como o sistema escreve e valida o estado?
• como o sistema responde leitura pesada e analítica?

Quando você mistura as duas, o core vira refém da consulta mais pesada do produto.

Exemplo simples

Imagine um sistema de assinaturas.

O fluxo transacional precisa:

• criar assinatura
• cobrar
• cancelar
• atualizar status

Mas o time de operações quer um painel com:

• MRR por plano
• churn por janela
• exportação por tenant
• filtros por região e canal

Se tudo isso for resolvido direto em query no modelo principal, logo o backend começa a otimizar o transacional para perguntas analíticas.

Um read model específico pode aceitar:

• atualização assíncrona
• colunas já agregadas
• formato mais amigável para filtro e exportação

O erro comum

O erro comum é dizer:

“vamos deixar no transacional até doer”

Às vezes faz sentido por um tempo.

Mas o problema é não reconhecer quando já doeu.

Outro erro comum é criar read model cedo demais, sem pergunta real.

Aí você constrói projeção ornamental.

Então o ponto não é criar read model para tudo.

É criar quando a pergunta pesada começa a distorcer o core.

O que normalmente ajuda

Ajuda bastante quando o time consegue responder:

• qual consulta está forçando índice, lock ou shape ruim demais?
• qual atraso é aceitável para esse relatório?
• esse read model pode ser reconstruído?
• ele serve uma pergunta clara ou um buffet genérico?

Read model bom costuma ser:

• específico
• reconstruível
• observável
• tolerante a atraso controlado

Como um senior pensa

Quem já tentou usar tabela transacional como ferramenta de BI costuma perguntar:

• estou otimizando o core para uma leitura que não deveria morar nele?
• qual é o SLA real desse relatório?
• compensa derivar um modelo separado?
• se eu separar, sei como detectar e corrigir drift?

Essa conversa evita tanto o improviso eterno quanto a complexidade teatral.

Ângulo de entrevista

Esse tema aparece em backend, analytics interno, dashboards, exportações e system design.

O entrevistador quer ver se você entende:

• que leitura pesada pode distorcer o desenho do transacional
• que read model é ferramenta de foco, não moda arquitetural
• que separação de leitura aceita trade-off consciente de atraso e reconstrução

Resposta forte costuma soar assim:

“Eu manteria o modelo transacional focado no fluxo crítico e criaria read model quando a leitura pesada começar a impor custo ou shape ruim demais ao core. O importante é que ele responda a uma pergunta clara e seja reconstruível.”

Takeaway direto

Read model para relatório não serve para parecer sofisticado.

Serve para impedir que consulta pesada mande no desenho do sistema inteiro.