Event Sourcing gets oversold. Every few months there's a wave of posts making it sound like the only legitimate way to build backend systems. Then there's a counter-wave calling it over-engineered nonsense. Both camps are wrong, and both camps usually haven't shipped a production system that genuinely needed it.
The real question isn't whether Event Sourcing is a good pattern. It is. The question is whether your specific problem warrants the complexity it brings, because that complexity is real and it compounds.
What You Actually Get
Event Sourcing stores state as a sequence of events rather than as a current snapshot. Instead of updating a row, you append an event. The current state is derived by replaying the events. This gives you a few things that are genuinely hard to get otherwise.
A complete audit trail by construction. Not a log you added as an afterthought — the audit trail is the system's primary storage. Every state transition is recorded, immutable, and replayable. For financial systems, healthcare, and anywhere regulatory compliance is a hard requirement, this is not a nice-to-have.
Temporal queries. You can reconstruct the state of any aggregate at any point in time. 'What was the account balance on this date?' is a query you answer by replaying events up to that timestamp, not by hoping someone had the foresight to store historical snapshots.
Event-driven integration without a separate outbox. The events you use for internal state are the same events you publish to other services. The integration is a consequence of the storage model, not an additional layer you bolt on.
What You Pay For It
Event streams grow. Replaying a long stream to get current state gets expensive. You need snapshots — periodic checkpoints of aggregate state that let you replay from a recent point rather than the beginning of time. Snapshots are not complex, but they're another moving part.
Querying becomes non-trivial. You can't do SELECT * FROM orders WHERE status = 'pending'. You need projections — read models built by consuming the event stream. You're building and maintaining a separate read layer. That's the trade-off. The write side becomes simple and auditable; the read side requires explicit modeling.
Schema evolution is harder. When you realize an event's structure was wrong, you can't just ALTER TABLE. You have versioned event schemas and upcasters. Plan for this from the start or it becomes painful.
The Honest Checklist
Event Sourcing is worth it if: audit trail is a non-negotiable business or regulatory requirement, you need temporal queries, you're already in an event-driven architecture and the integration story matters, or you have a domain with complex, branching state transitions that are genuinely hard to model as snapshots.
It's probably not worth it if: you're building a CRUD service, the team hasn't worked with it before and the delivery timeline is tight, or the 'audit requirement' is vague and might be satisfied with a simple append-only log table.
The pattern is powerful. Use it where it fits, not everywhere you can get away with it.