Dev Mehta
Backend & Infra
When we started BuildFlow, we made one rule about the audit log: it cannot be opt-in, and it cannot make the app feel slower. Both rules sound easy. Neither is.
An audit log that fires only when someone toggles it on is not an audit log — it's a feature you forget to turn on before the breach. So we wired ours into every mutation path at the data-access layer. Every create, update, delete, role change, or invitation gets a row in audit_events, in the same transaction as the operation it describes.
Same transaction, different latency budget
The naive version writes a JSON blob with the full before/after of every mutation. That doubles write amplification and tanks p95 latency. We separated the hot path (a thin event with ids and op codes) from the cold path (a deferred materialization job that joins back to the entity at read time).
- Hot path: write a ~120-byte event row, indexed by (workspace_id, created_at).
- Cold path: a background job hydrates a `audit_events_materialized` view for export and search.
- Reads: filtered by tenant and time, paginated by id, never by offset.
Append-only is a discipline, not a column
We enforce append-only at three layers: a Postgres RULE that blocks UPDATE/DELETE on the table, a check at the ORM layer that fails the migration if anyone adds a destructive trigger, and an integration test that tries to mutate a historical row and asserts that it cannot.
“If you can't delete an audit row, you can't quietly delete the truth.”
What we'd do differently
We'd start with the partition strategy on day one. Going from a single audit_events table to monthly partitions was a multi-week project we could have avoided. If you're building an audit log today: partition by month, index by (workspace_id, event_time), and write the export job before you write the UI for it.