How 2 Soft Delete.

Em sistemas modernos, a restauração de dados é uma demanda real, seja por erro do usuário, auditoria ou suporte. O objetivo deste guia é apresentar o conceito do Soft Delete, assim como suas principais estratégias de forma interativa, para que você possa testar e escolher a melhor abordagem para o seu próximo projeto.

O Problema

Imagine o seguinte cenário, um usuário passa o dia cadastrando um projeto complexo. Por um erro de clique ou confusão na UI, ele deleta o registro. O suporte é acionado, mas o backup é semanal. O dado sumiu. Isso acontece porque, por padrão, usamos o Hard Delete (DELETE FROM table). O registro é removido fisicamente do disco e não há caminho de volta sem um snapshot do banco.

Aqui esta um exemplo de Hard Delete:

O Hard Delete é perigoso para tabelas críticas, mas é a abordagem ideal (e nativa) para dados irrelevantes, registros temporários ou cadastros rápidos que não impactam o negócio.

A Solução

O Soft Delete trata a exclusão como um estado lógico, não físico. Para o usuário, o dado sumiu, mas para o banco ele apenas foi marcado como oculto. Existem duas principais formas de se implementar isso, que são o que chamamos de Soft Delete Patterns.

Logical Delete

É a abordagem mais simples e comum. Consiste em adicionar uma coluna na própria tabela para sinalizar o estado do registro.

Aqui esta uma forma de fazer Logical Delete:

Para implementar o Logical Delete, basta adicionar uma nova coluna em sua tabela:

ALTER TABLE users
ADD COLUMN archived_at TIMESTAMPTZ DEFAULT NULL;

Esse campo pode ser um booleano ou um timestamp. O importante é que ele indique claramente se o registro está ativo ou deletado.

O problema surge em larga escala. Milhões de registros deletados continuam ocupando espaço e sujando seus índices na tabela principal.

Aqui esta um desafio comum do Logical Delete:

Isso pode degradar a performance de queries simples, já que o banco precisa filtrar dados mortos constantemente.

Shadow Table

Para resolver o inchaço da tabela principal, subimos o nível de complexidade com o Shadow Table. Aqui, em vez de marcar o registro, nós o movemos para uma tabela secundária de arquivo.

Aqui esta uma forma de fazer Shadow Table:

Para implementar o Shadow Table, a complexidade aumenta, primeiro devemos criar a seguinte função em nosso banco de dados:

CREATE OR REPLACE FUNCTION fn_shadow_archive()
RETURNS TRIGGER AS $$
DECLARE
v_cause_table TEXT;
v_cause_id_text TEXT;
BEGIN
v_cause_table := current_setting('app.current_deleter_table', true);
v_cause_id_text := current_setting('app.current_deleter_id', true);

IF (v_cause_table IS NULL OR v_cause_table = '') THEN
v_cause_table := TG_TABLE_NAME;
v_cause_id_text := OLD.id::text;

PERFORM set_config('app.current_deleter_table', v_cause_table, true);
PERFORM set_config('app.current_deleter_id', v_cause_id_text, true);
END IF;

INSERT INTO archives (
table_name,
record_id,
data,
caused_by_table,
caused_by_id
)
VALUES (
TG_TABLE_NAME,
jsonb_build_object('id', OLD.id),
to_jsonb(OLD),
v_cause_table,
jsonb_build_object('id', v_cause_id_text)
);

RETURN OLD;
END;
$$ LANGUAGE plpgsql;

Essa função é responsável por pegar o registro deletado e inserir ele na tabela archives.

Agora basta criarmos os triggers para as tabelas críticas. Assim, elas ficam protegidas contra Hard Delete. No exemplo abaixo, o padrão de Shadow Table será aplicado em três tabelas: users, establishments e schedulings.

CREATE TRIGGER trg_archive_users BEFORE DELETE ON users FOR EACH ROW EXECUTE FUNCTION fn_shadow_archive();
CREATE TRIGGER trg_archive_establishments BEFORE DELETE ON establishments FOR EACH ROW EXECUTE FUNCTION fn_shadow_archive();
CREATE TRIGGER trg_archive_schedulings BEFORE DELETE ON schedulings FOR EACH ROW EXECUTE FUNCTION fn_shadow_archive();

Nada é de graça. Enquanto o Logical Delete exige apenas um UPDATE, restaurar dados em uma Shadow Table exige queries de INSERT INTO e SELECT mais complexas, especialmente se houver relacionamentos de chaves estrangeiras envolvidos.

Aqui esta um desafio comum da Shadow Table:

Conclusão: Qual escolher?

Na prática, a melhor estratégia de exclusão depende muito do momento do produto e do nível de maturidade da arquitetura. Não existe resposta única: existe escolha consciente por contexto.

Para POCs e fases iniciais, o Logical Delete costuma fazer mais sentido. Ele entrega segurança para recuperar dados com implementação rápida, baixo atrito e sem elevar cedo demais a complexidade do projeto.

Para MVPs robustos, pilotos e produto final em produção, o Shadow Table pode ser bem mais vantajoso. Apesar do custo maior de implementação, ele ajuda a manter a tabela principal mais limpa, melhora previsibilidade de performance e organiza melhor a estratégia de arquivamento.

Existem outros patterns de soft delete além dos citados aqui. Neste artigo, eu trouxe os mais conhecidos e os que já usei na prática, justamente para compartilhar decisões que testei em cenários reais.