An organisation wants event sourcing for its order platform because it is considered scalable. What business or audit requirements would actually justify it, and when is CRUD plus an audit log safer?

Why "scalable" is the wrong justification

Appending is indeed cheaper than updating, but event sourcing does not remove the need for current state — it moves that cost to read time, where it is paid through projections, snapshots and caches that must each be built and operated. The total system is more complex and typically has more moving parts under load, not fewer. Teams adopting it for throughput reasons generally discover the throughput was never the constraint.

What genuinely justifies it

1. History is a first-class product requirement. "What did this order look like on 3 March?" "Replay these six months with the corrected tax rule." "Show every state this shipment passed through, with timing." If those are features rather than diagnostics, storing state and hoping the log is sufficient will not work, because a log written alongside state is not guaranteed to reconstruct it.

2. Retroactive correction with recomputation. In domains where a rule changes and past results must be recomputed — pricing corrections, rebate calculations, regulatory restatements — replaying events against new logic is the natural implementation, and the alternative is a bespoke recalculation engine per rule.

3. Multiple independent interpretations of the same facts. Different consumers deriving different models from one event stream, where new consumers must be able to derive their model from all of history rather than from the moment they were added.

4. The events are the domain's real vocabulary. In some domains — trading, logistics, insurance claims — practitioners already think in events. There, the model is a better fit, not merely a technique.

When CRUD plus an audit log is safer

For most transactional systems, including most order platforms. It gives:

• Current state directly queryable, with no projection lag and no rebuild machinery.
• An append-only audit table, written in the same transaction, satisfying every audit requirement anyone has actually stated.
• Ordinary tooling — every engineer can read it, every backup restores it, every reporting tool queries it.
• Schema changes as migrations, rather than as versioned event schemas that must be readable forever.

The last point deserves emphasis: events are immutable, so every version of every event schema must remain interpretable for the life of the system. Five years in, the replay code contains handling for event versions written by systems nobody remembers. That is a permanent tax, and it is the cost most teams fail to anticipate.

The middle path most systems should take

Event sourcing within one bounded context where history genuinely matters — payments, ledger, inventory movements — and conventional state elsewhere. The mistake is adopting it as a platform-wide architecture on the strength of a requirement that applies to one subsystem.

The interview-grade point

Ask what question the business needs answered that current state cannot answer. If there is a concrete one, event sourcing is a strong candidate. If the answer is "we might need it later", an append-only audit table gives you the option at a fraction of the cost, and you can adopt event sourcing later for the one context that turns out to need it.