Implementar uma política de retenção como jobs de exclusão

Objetivo

Transformar uma política de retenção escrita (por exemplo: registros de sessão 30 dias após a última atividade, tickets de suporte dois anos após o fechamento) em jobs que excluem no prazo, de forma verificável e sem derrubar o serviço. Definir quais prazos são adequados para quais dados é uma decisão organizacional e não faz parte deste método.

Pré-requisitos

Uma tabela de retenção: uma linha por classe de dados, com o armazenamento, o marco que inicia o prazo (criação, última atividade, fechamento), o prazo e o responsável. Toda tabela ou bucket que contenha dados pessoais corresponde a uma linha. Timestamps a partir dos quais o prazo possa ser calculado (uma coluna closed_at, e não um flag de status sem data).

Passos

1. Escolha o mecanismo para cada armazenamento. Tabelas particionadas por tempo: remova (drop) ou desanexe (detach) a partição expirada; a documentação do PostgreSQL afirma que DROP TABLE ou ALTER TABLE DETACH PARTITION em uma partição é muito mais rápido do que uma operação em massa e evita o overhead de VACUUM de um DELETE em massa, que ambos exigem um lock ACCESS EXCLUSIVE na tabela pai e que DETACH PARTITION ... CONCURRENTLY precisa apenas de um lock SHARE UPDATE EXCLUSIVE. Armazenamento de objetos: regras de ciclo de vida; a documentação do Amazon S3 descreve ações de expiração que excluem objetos expirados em nome da conta. Todo o resto: um DELETE ... WHERE clock < now() - interval em lotes, com um limite fixo de linhas por iteração e uma pausa entre iterações, sendo o limite definido a partir da carga observada no armazenamento.
2. Escreva o job de modo que seja idempotente e retomável: cada execução seleciona o próximo lote de linhas expiradas, exclui, registra a contagem e termina; uma falha no meio da execução não causa prejuízo.
3. Exclua primeiro os dependentes, ou use ON DELETE CASCADE de forma deliberada e registre a cascata na tabela de retenção.
4. Agende o job com um lock, para que duas instâncias nunca rodem ao mesmo tempo; emita por execução: linhas examinadas, linhas excluídas e idade da linha mais antiga restante.
5. Crie um alerta sobre a linha mais antiga restante: se qualquer linha for mais antiga que o prazo somado a uma margem de tolerância, o job está com defeito, independentemente de reportar erros ou não.
6. Comece em modo dry-run: conte o que seria excluído, compare com o esperado e só então ative.
7. Propague: armazenamentos derivados (índice de busca, tabelas de analytics, caches) ou expiram sozinhos pelo mesmo prazo, ou assinam os eventos de exclusão.

Resultado esperado

Toda classe de dados tem um job ou uma regra de ciclo de vida, uma métrica e um alerta; a idade da linha mais antiga permanece abaixo do prazo; a retenção passa a ser uma propriedade do sistema em execução, e não de um documento.

Limites e base de verificação

Os backups ficam fora da política; a retenção própria de um backup determina por quanto tempo os dados excluídos sobrevivem. Registros sob bloqueio (hold) precisam de um flag de isenção por registro que o job respeite; quais casos exigem isso não é tratado aqui. O comportamento de locks e de ciclo de vida segue a documentação citada; não se afirma nenhum número de throughput.