DEV Community: Marc

Your event store is already your audit log

Marc — Wed, 01 Jul 2026 07:51:25 +0000

Your event store is already your audit log

Almost every SaaS I've worked on ends up with an audit_log table. Someone files a compliance ticket — "we need to know who changed what and when" — and a new table appears next to the domain tables. Then the real work starts: writing to it on every mutating endpoint, keeping it in sync, and quietly discovering six months later that three endpoints forgot to log.

That table is a second source of truth. And second sources of truth drift.

What an audit log actually needs

Strip the compliance language away and an audit entry is five fields:

who did it
when they did it
what they touched (which entity)
which action it was
the delta — what actually changed

Plus, for a multi-tenant app: whose data it was, so tenant A can never read tenant B's history.

Now look at what an event in an event-sourced system carries. Every state change is an appended event with createdBy, createdAt, tenantId, aggregateType + aggregateId, type, and a payload holding the delta.

That's the same five fields. The event log already is the audit trail — append-only, ordered, and impossible to forget to write, because writing the event is how state changes in the first place. There's no code path that mutates data without producing an event.

So don't build the table. Query the log.

If the audit trail is already there, the whole "audit feature" collapses into one privileged read over the events table:

export const listQuery = defineQueryHandler({
  name: "list",
  schema: z.object({
    aggregateType: z.string().optional(),
    aggregateId: z.uuid().optional(),
    eventType: z.string().optional(),
    userId: z.string().optional(),
    from: z.iso.datetime().optional(),
    to: z.iso.datetime().optional(),
    limit: z.number().int().min(1).max(100).default(50),
    before: z.string().optional(), // cursor
  }),
  access: { roles: ["Admin", "SystemAdmin"] },
  handler: async (query, ctx) => {
    const p = query.payload;
    const where = { tenantId: query.user.tenantId }; // tenant-isolated at the WHERE
    if (p.aggregateType) where.aggregateType = p.aggregateType;
    if (p.aggregateId)   where.aggregateId   = p.aggregateId;
    if (p.eventType)     where.type          = p.eventType;
    if (p.userId)        where.createdBy      = p.userId;
    // ...time range + cursor omitted for brevity

    return selectMany(ctx.db, eventsTable, where, {
      orderBy: { col: "id", direction: "desc" },
      limit: p.limit,
    });
  },
});

No table, no projection, no write path, no sync job. The filter surface an audit UI wants — by entity, by actor, by action, by time — is just WHERE clauses over columns the events already have.

The two things you still owe

Reusing the event log doesn't come completely free. Two concerns are real:

1. Access control. The event log is the most sensitive read in the system — it's literally everything that ever happened. Gate it hard (Admin / SystemAdmin above) and pin tenant isolation into the WHERE clause itself, not into application logic that a future refactor can bypass. Cross-tenant peeking should be structurally impossible, not politely discouraged.

2. PII. If you dump raw event payloads into an audit view, you'll surface fields you didn't mean to. The clean fix is to strip sensitive values at append time — mark them in the entity definition and never let them into the stored event. Then the audit read physically cannot leak them, because they were never written. Doing it at read time is a filter you'll eventually forget on some new field; doing it at write time is a guarantee.

When this doesn't apply

Honesty: this only works if you're actually event-sourced. If your system does in-place UPDATEs, there's no historical record to query — you genuinely need to start capturing one, and a dedicated table (or CDC/logical decoding off the WAL) is the pragmatic path. This isn't an argument to adopt event sourcing for audit; it's an argument that if you already have it, the second table is redundant.

One caveat even when it fits: event schemas evolve, so your audit reader sees heterogeneous historical payloads. For an audit log that's a feature — you want the exact shape as it was written — but don't mistake it for a clean queryable projection.

The point

An audit log isn't a thing you build. It's a view onto history you're already keeping. If you're appending events, you've been sitting on a complete, tamper-evident audit trail the whole time — the only missing piece was a gated query with the right WHERE clauses.

This is exactly how the audit feature works in Kumiko, a Bun/TypeScript framework where multi-tenancy, GDPR, and audit are bundled features rather than boilerplate you rewrite per project — one ~40-line query handler, no separate table.

How do you prevent AI-generated code from drifting away from your conventions over time?

Marc — Sun, 28 Jun 2026 10:52:37 +0000

We've been generating production features with AI for a while now — auth flows, billing hooks, notification handlers. And we've hit a pattern we don't have a good answer to yet.

The first feature the AI generates looks great. It reads the codebase, picks up the patterns, and the output looks like something a senior dev wrote.

The tenth feature? Less so. Small inconsistencies creep in:

A handler that doesn't follow the error-handling convention
A schema field with a different naming pattern
A test that checks existence instead of behavior

None of it is wrong. All of it is subtly inconsistent.

Fixes we've tried

AGENTS.md / CLAUDE.md — helps, but gets stale and doesn't scale with the codebase

Code review — catches it, but defeats some of the speed advantage

Linting + formatting — catches easy stuff, misses semantic drift

What we haven't solved: giving the AI a "living" representation of your conventions that stays current as the codebase evolves.

We're building Kumiko — an opinionated SaaS framework — partly as an answer to this. If the framework constrains what's possible, drift has less surface area. But I'm not convinced that fully solves it either.

Curious what's actually working for others

Do you just review AI output carefully and accept some drift?
Custom guards / linters that encode your conventions?
Something that auto-generates AGENTS.md from the codebase?

What's your approach?

Multi-Tenancy in Bun/Hono Without Boilerplate

Marc — Wed, 24 Jun 2026 19:11:12 +0000

Every multi-tenant SaaS has the same problem: you need to make sure every query only returns data for the right tenant. Forget a WHERE tenant_id = ? once, and you have a data leak.

The obvious solution — a separate database per tenant — doesn't scale. Connections are expensive, migration overhead multiplies, and you lose cross-tenant reporting.

For Kumiko we went a different route: a single DB pool, but every query automatically gets the tenantId injected — without handler code ever having to do it manually.

The Idea: TenantDb Instead of a Raw DbRunner

Instead of passing a raw DB connection around, we create a TenantDb wrapper per request:

const db = createTenantDb(rawDb, tenantId)

From that point, db behaves like a normal database — but with automatic isolation baked in:

// Handler code — no tenantId needed
const users = await ctx.db.selectMany(usersTable)
// → SELECT * FROM users WHERE tenant_id IN ('tenant-123', 'system')

await ctx.db.insertOne(usersTable, { name: 'Max' })
// → INSERT INTO users (name, tenant_id) VALUES ('Max', 'tenant-123')

await ctx.db.updateMany(usersTable, { name: 'Moritz' }, { id: userId })
// → UPDATE users SET name='Moritz' WHERE id=? AND tenant_id='tenant-123'

Handlers write plain CRUD code. Isolation happens underneath — invisible, but enforced.

How the Injection Works

Reads: own rows + reference data

Read queries always see two tenants: the current one and SYSTEM_TENANT_ID. This allows reference data (e.g. global config) to be visible to all tenants without duplicating it:

// tenantId filter === [currentTenantId, SYSTEM_TENANT_ID]

If a handler passes its own tenantId in the WHERE clause, it can only narrow the scope, never widen it. A where: { tenantId: 'other-tenant' } is silently dropped.

Writes: own rows only

Inserts get tenantId forced in — and the value cannot be overridden by the caller:

// mode === "tenant": tenantId on INSERT is enforced last
return { ...data, tenantId }  // overwrites whatever the handler passed

Updates and deletes without a WHERE clause throw an error instead of hitting all rows:

// Prevents accidental mass-updates
"TenantDb.updateMany without where would mass-update all tenant rows."

System mode for operators

For admin screens there's r.systemScope() — queries run unfiltered across all tenants. Explicit opt-in only, never the default.

Tenant Resolution in Hono

TenantDb needs a tenantId. It comes from middleware that resolves it from the request — either from the hostname (for custom domains) or from the JWT:

// Middleware (simplified)
app.use('*', async (c, next) => {
  const tenant = await resolveTenant(c.req)
  c.set('db', createTenantDb(rawDb, tenant.id))
  await next()
})

Every handler then gets proper isolation through ctx.db — without a single line of tenant logic in actual feature code.

What This Means in Practice

Across three years of production use and several apps (CashColt, publicstatus, kumiko-studio) we've had zero data leak bugs from forgotten tenant filters. Not because we were particularly careful, but because it's structurally impossible to forget.

The overhead: nearly zero. A few extra conditions per query, no extra DB connection pool, no migration overhead multiplied per tenant.

If you want to try the framework: kumiko.rocks — open source under BUSL-1.1.