Políticas de retenção de estado derivado sem acumular lixo operacional

O problema

Estado derivado nasce com boa intenção.

Pode ser:

• projeção
• snapshot
• tabela auxiliar
• materialização para leitura
• cache persistido
• fila de reprocessamento

O ganho aparece rápido.

O problema aparece meses depois, quando ninguém mais sabe:

• por que aquilo ainda existe
• quanto tempo deve ficar
• se pode apagar
• se dá para reconstruir

Aí o sistema começa a carregar peso morto operacional.

Modelo mental

Estado derivado não é fonte da verdade.

Então ele precisa de duas definições explícitas:

• para que serve
• qual é o ciclo de vida dele

Nem todo dado derivado precisa viver para sempre.

Alguns precisam:

• poucas horas
• alguns dias
• uma janela regulatória
• enquanto forem úteis para leitura rápida

Sem essa conversa, retenção vira default infinito.

Exemplo simples

Imagine um sistema que mantém:

• snapshot de carrinho
• projeção para painel operacional
• tabela de agregação por tenant
• histórico auxiliar para retry

Se tudo isso ficar guardado sem política, você ganha:

• storage inchado
• rebuild mais caro
• reconciliação mais lenta
• dúvida eterna sobre o que ainda vale

Às vezes o time está pagando para manter derivado velho que nem produto nem operação usam mais.

O erro comum

O erro comum é este:

“deixa guardado, vai que um dia precisa”

Isso costuma esconder uma de três coisas:

• medo de apagar sem saber reconstruir
• ausência de política de retenção
• confusão entre dado fonte e dado derivado

Outro erro comum é aplicar TTL aleatório sem olhar consequência operacional.

Apagar sem critério também quebra.

O que normalmente ajuda

Normalmente ajuda classificar o derivado por quatro perguntas:

• ele é reconstruível?
• ele é consultado com frequência real?
• ele existe por motivo operacional, de produto ou de auditoria?
• qual é o custo de mantê-lo vivo?

Na prática, isso costuma virar uma de quatro decisões:

• expirar
• compactar
• arquivar
• reconstruir sob demanda

O ponto não é inventar política sofisticada.

É não deixar o sistema crescer por inércia.

Como um senior pensa

Quem já teve que limpar backend inchado costuma perguntar:

• isso ainda serve a uma pergunta real?
• se eu apagar hoje, quem sente falta de verdade?
• consigo rebuildar quando necessário?
• o custo de retenção está escondendo falta de disciplina operacional?

Essa conversa geralmente reduz bastante lixo acumulado.

Ângulo de entrevista

Esse tema aparece em read models, analytics interno, jobs, reprocessamento e operação de sistemas.

O entrevistador quer ver se você entende:

• que derivado também precisa de ciclo de vida
• que retenção é decisão de arquitetura, não só de storage
• que rebuild e expiração fazem parte da maturidade operacional

Resposta forte costuma soar assim:

“Eu trataria estado derivado como artefato com propósito e prazo, não como dado eterno por padrão. Definiria se ele é reconstruível, qual janela realmente precisa ficar viva e quando expirar, compactar ou arquivar para não acumular custo e drift desnecessários.”

Takeaway direto

Estado derivado sem política de retenção vira depósito.

E depósito operacional sempre cobra aluguel.