A brokerage proposes event sourcing for its account ledger. What requirements would genuinely justify it, and when is conventional state plus an audit trail the safer choice?

What genuinely justifies it

• The event is the business record. In a ledger, "deposited 5,000", "bought 10 shares", "paid brokerage" are the facts; the balance is a derived opinion about them. When that is true, event sourcing is not an architectural pattern, it is an accurate model of the domain — and double-entry bookkeeping has worked this way for centuries.
• Temporal queries are a functional requirement. "What was this portfolio worth at 3pm on the day of the circuit breaker" is a real regulatory and support question, and it is trivial with events and painful with mutable state.
• Auditability must be structural rather than procedural. A regulator asking for an immutable, ordered, complete record is asking for an event log, and an append-only log gives it by construction rather than by discipline.
• Corrections must be recorded rather than applied. In finance you do not overwrite an error, you post a reversing entry. That is exactly the event-sourcing model.

What it costs

• Projections and their rebuild path, which must be fast enough to be usable after a bug.
• Schema evolution on events that are immutable and permanent. An event written three years ago must still be readable, and upcasting old versions is ongoing work forever.
• A different mental model for every engineer who joins, and a much larger space of ways to get it wrong.
• Erasure requirements that conflict directly with immutability, which in a regulated consumer product is a real and unavoidable tension — usually resolved by keeping personal data outside the event stream behind a reference, so the reference can be tombstoned without breaking the log.

When conventional state plus an audit trail is safer

When the audit requirement is "show who changed what and when" rather than "reconstruct any past state", an append-only audit table alongside a normal mutable model gives most of the value for a small fraction of the cost — and it does not put the entire team on an unfamiliar model.

Event sourcing chosen for sophistication rather than for a stated requirement is among the most expensive architectural mistakes available, because it is very hard to reverse: once the events are the record, a migration back means reconstructing state and losing history.

The scoping judgement

Event-source the ledger. Do not event-source the user's notification preferences. The pattern belongs to the part of the domain where history is the truth, and applying it everywhere is how teams end up rebuilding projections to change a display name.