advanced 2 min answer

A team wants event sourcing for a new order service, citing audit requirements. What do you recommend?

event-sourcingauditdecision-making
Show the full answer Hide the answer

The recommendation: probably an audit log, not event sourcing

If the requirement is audit, event sourcing is a very expensive way to obtain it. An append-only audit table — who, what, when, before, after — satisfies audit requirements, is understood by everyone, and costs almost nothing.

Event sourcing is a decision about the system of record: state is derived by folding events rather than stored. It brings the audit trail as a by-product, and it brings much more besides.

What event sourcing genuinely buys

Temporal queries — the state of any aggregate at any past instant, reconstructible exactly. Retroactive read models — building a projection over history that nobody anticipated when the events were written, which is a real and recurring advantage. Debugging by replay — reproduce a bug by replaying the exact event sequence. A domain model expressed in business events, which for some domains genuinely clarifies the design.

If the team wants those, it is a legitimate choice.

What it costs, permanently

Events are forever, so schema evolution means an upcasting chain that grows monotonically and is never deleted.

GDPR erasure conflicts directly with an append-only log. The answers are crypto-shredding or keeping personal data out of events behind a reference — both design decisions that must be made before the first event is written, not after.

Every query needs a projection, each of which must be idempotent, ordering-aware, rebuildable and monitored.

Onboarding is slower — the pattern is unfamiliar to most engineers, and mistakes in it are subtle.

Concurrency requires expected-version appends, and getting that wrong produces streams that violate their own invariants.

The test I would apply

Ask them to describe a query they cannot answer without it. If every example is "who changed what and when", the requirement is an audit log. If the examples are "reconstruct the order book as of 3pm last Tuesday" or "build a new analysis over three years of history", event sourcing is earning its cost.

What a strong answer adds

Noting the middle option that satisfies most of these cases: emit domain events for integration and audit while keeping state in a normal table. You get the events, the audit trail, the integration capability and the read models, without making the event log the system of record — and therefore without the erasure conflict, the upcasting obligation, or the rehydration cost.