Como você projeta um audit log para anos de rastreabilidade?

Question

IT Interview Practice · Accepted Answer

Torne-o **append-only e imutável**, encadeie cada entrada à anterior com um **hash** para que adulteração seja detectável, **particione por tempo** para que dados antigos saiam de forma barata, e arquive partições seladas em **object storage WORM** (write-once) com uma política de retenção — nunca permita `UPDATE`/`DELETE` em registros vivos.

```text
service ──emit event──▶ append-only writer
                             │  hash = H(prev_hash || payload)
                             ▼
                     audit_2026_07 (hot partition)  ◀── query by actor/time
                             │ month sealed
                             ▼
                     WORM object store (S3 Object Lock)  ── retention: 7y
                             │
                     periodic anchor: publish latest hash externally
```

## Append-only e evidência de adulteração

O valor inteiro de um audit log é que você pode **confiar nele depois**, então o schema deve proibir mutação. Conceda ao app apenas `INSERT` — sem `UPDATE`/`DELETE` — e imponha isso no nível de role do DB, não só no código. Além disso, construa uma **hash chain**: cada linha armazena `hash = SHA256(prev_hash || this_row)`. Mude qualquer linha histórica e todo hash subsequente quebra, então a adulteração é *detectável* mesmo por alguém com acesso ao DB. Periodicamente **ancore (anchor)** o último hash em algum lugar que você não controla (um cartório, um ledger público, um email assinado) para que até um admin que reescreva toda a cadeia não consiga bater com o valor ancorado.

## Particionamento por tempo e retenção

Logs multi-ano crescem sem limite, então **particione por tempo** (ex. partições de range mensais). Benefícios: consultas filtram por partição, e aposentar dados antigos é um `DETACH`/`DROP PARTITION` de metadados — instantâneo, não um `DELETE` gigante que incha a tabela. Partições seladas migram para **armazenamento WORM** — o S3 Object Lock em *compliance mode* impede fisicamente a deleção até a data de retenção, satisfazendo regulações como SOX/HIPAA. Mantenha os meses recentes quentes no Postgres para consultas rápidas; tudo mais antigo fica frio no object storage, consultado sob demanda.

## Perspectiva de entrevista

A sondagem é se você entende que "audit log" significa **imutabilidade e comprovabilidade**, não apenas "uma tabela com um timestamp". Bom: tabela append-only. Excelente: append-only *imposto por role do DB*, hash chain com ancoragem externa, particionamento por tempo para retenção, WORM para compliance. Armadilha comum: armazenar linhas de auditoria na mesma tabela mutável do app (um bug ou um DBA malicioso pode reescrever silenciosamente a história) — auditores rejeitarão.

## Trade-offs e modos de falha

- **A hash chain serializa escritas** — cada entrada precisa do hash anterior, então um design ingênuo gargala. Agrupe entradas ou encadeie por shard e faça cross-link periodicamente.
- **O armazenamento cresce para sempre**; sem particionamento + tiering para object storage barato, custo e latência de consulta explodem.
- **O compliance mode do WORM é irreversível** — uma configuração de retenção errada tranca os dados (ou os deixa expirar) sem desfazer; teste primeiro em governance mode.
- **Clock skew / eventos fora de ordem** corrompem o raciocínio baseado em tempo — registre tanto o tempo do evento quanto o de ingestão, e nunca confie em relógios do cliente para ordenação.

Append-only e evidência de adulteração

Particionamento por tempo e retenção

Perspectiva de entrevista

Trade-offs e modos de falha

Perguntas relacionadas