Tombstone e exclusão lógica em estados derivados sem drift eterno

O problema

Remover dado parece simples.

Na prática, quase nunca é.

Principalmente quando o sistema tem:

• projeções
• índices
• snapshots
• read models
• caches persistidos

Se o fonte apaga e o derivado não entende isso direito, nasce o clássico fantasma operacional:

• dado sumiu de um lado
• continua aparecendo do outro
• ninguém sabe se é bug ou política

Modelo mental

Vale separar três decisões:

• exclusão lógica no fonte
• tombstone para propagar remoção
• retenção do próprio marcador de exclusão

Essas três coisas não são automaticamente a mesma.

O que importa é a semântica:

• o dado deixou de existir?
• deixou de ser visível?
• ainda precisa ser auditável?
• o derivado precisa saber disso por quanto tempo?

Exemplo simples

Imagine um catálogo interno com produtos e um read model para busca.

Quando produto sai do ar, o sistema fonte pode:

• marcar deleted_at
• emitir evento de remoção
• manter tombstone por uma janela

Se nada disso estiver claro, a busca pode:

• continuar mostrando item removido
• remover cedo demais algo ainda auditável
• rebuildar e ressuscitar coisa que não devia voltar

O erro comum

O erro comum é tratar soft delete como solução universal.

Ele não é.

Às vezes é útil.

Às vezes só adia a decisão.

Outro erro comum é largar tombstone para sempre sem política de limpeza.

Aí você ganha:

• storage extra
• lógica confusa
• rebuild mais caro
• reconciliação eterna

O que normalmente ajuda

Normalmente ajuda decidir explicitamente:

• qual consumidor precisa saber da remoção
• por quanto tempo o tombstone precisa viver
• se o derivado reconstrói a partir do fonte ou do histórico de eventos
• quando a remoção pode ser compactada ou eliminada

Na prática, a escolha boa depende menos de dogma e mais de:

• auditabilidade
• reconstruibilidade
• custo operacional
• semântica do produto

Como um senior pensa

Quem já viu estado fantasma em produção costuma perguntar:

• este tombstone existe para quê exatamente?
• se eu apagar esse marcador, quem perde contexto?
• o rebuild sabe preservar remoção ou vai ressuscitar registro?
• soft delete aqui é regra de negócio ou medo de apagar?

Essa conversa reduz bastante drift invisível.

Ângulo de entrevista

Esse tema aparece em event-driven systems, read models, busca, analytics interno e operações de dados.

O entrevistador quer ver se você entende:

• que remoção também precisa de contrato
• que derivado precisa saber esquecer de forma coerente
• que tombstone sem política vira lixo operacional

Resposta forte costuma soar assim:

“Eu trataria remoção como parte explícita do contrato do derivado. Se usar tombstone, definiria por quanto tempo ele precisa existir e como o rebuild preserva essa semântica. O importante é não deixar o sistema acumular soft delete e marcador eterno sem uma razão clara.”

Takeaway direto

Estado derivado também precisa aprender a esquecer.

Se esquecer mal, o sistema passa a mentir devagar.