Event sourcing has been a standard conference talk for the last decade. Books have been written, workshops run, blog posts piled on. What fraction of real production systems actually use it?
From what I’ve seen: some systems use event sourcing and get serious value from it, but they’re rare. Here’s where it actually earns its place and the common misconceptions around it.
What event sourcing means (again)
In the classic approach you store an entity’s current state. When the user’s email changes, the email column in the database changes.
With event sourcing you don’t store the current state, you store the events that produced it: UserCreated, EmailChanged, PasswordReset, ProfileUpdated. The current state is computed by replaying the events.
On paper it’s great:
– Audit log for free
– Time travel (return to any past state)
– Multiple projections (different views from the same events)
– Easy debug and replay
In practice?
Three places event sourcing actually earns its keep
1. Financial systems. Banks, payment services, accounting systems. Every transaction has to be recorded historically, audit trails are mandatory, and data can’t be deleted. Event sourcing answers those needs natively.
Stripe’s backend is event-sourced. Ledger as the source of truth. Transactions live in an append-only log, and the current balance is derived state.
2. Complex workflow state machines. An order lifecycle going through 15 states: placed, validated, authorized, paid, reserved, packed, shipped, in-transit, delivered, returned, refunded, and so on. Every transition needs auditing, and debugging needs the ability to return to a prior state.
In systems like that, event sourcing answers “what exactly happened to this order?”. Plain CRUD only has the current state, and keeping history in a separate table adds two or three times the complexity.
3. Collaborative editing / real-time sync. Google Docs, Figma, that family. Every edit is an operation or event. Multiple clients publish operations against the same document and each replays them in their own order.
That rests on operational transformation (OT) and CRDTs, with event sourcing as a foundational block of the architecture.
Common misconceptions
Misconception 1: “Modern systems have to be event-sourced.”
Wrong. Most CRUD apps don’t benefit from event sourcing. Blogs, admin panels, simple e-commerce. Updating state directly is simpler and more performant.
Misconception 2: “Event sourcing is part of CQRS.”
Wrong. CQRS works without event sourcing. Event sourcing works without CQRS. They get lumped together because they’re often discussed in the same breath.
Misconception 3: “Event stores scale easily because they’re append-only.”
Partially true. Scaling the write side is easy (append-only, immutable). The query and projection side need serious optimisation. You can’t replay billions of events on every read, you have to keep snapshots.
Misconception 4: “Event schema doesn’t matter.”
Events live for five or ten years. Schema evolution is critical. If you aren’t disciplined about forward and backward compatibility, at some point the system can’t deserialise old events.
Misconception 5: “Replay is always deterministic.”
Wrong. If the business logic during replay depends on external services (a payment gateway call, sending an email), replay isn’t deterministic. Side effects have to be idempotent.
The cost of event sourcing on a small project
A three-person team spins up event sourcing. What happens?
Months 1 to 2: every developer is learning event store, projection, and snapshot concepts. Productivity is low.
Months 3 to 6: first major refactor. The event schema was designed wrong and needs migrating. Upgrading events in production is a big job.
Months 6 to 12: projection rebuild performance problems. Replaying millions of events takes hours. You have to put a snapshot strategy in place.
Year 1+: team is finally productive. But still chasing complex bugs.
That’s an investment most projects can’t carry. It pays off in specific financial and audit-critical systems. For general-purpose apps it’s overkill.
Hybrid: log the event, keep the state
A way to get similar benefits without the full event-sourcing complexity: a hybrid model.
Write current state to the database (normal CRUD). At the same time, write key events to an audit-log table: UserEmailChanged, SubscriptionUpgraded, PermissionGranted.
That approach:
– Queries stay fast (read from current state)
– You get an audit trail (from the event log)
– You can replay for debugging and history (from the event log)
– Without full event sourcing complexity
For most projects that hybrid is optimal. On consulting projects I usually recommend it. I only move to full event sourcing when audit or compliance really requires it.
Decision criteria
Should I actually do event sourcing? If you answer yes to all of these:
- Is audit trail a legal/compliance requirement (banking, healthcare)?
- Does my entity lifecycle involve 10+ state transitions?
- Do I frequently ask “how did this state arrive?” during debugging?
- Do I have multiple projection needs (different views from the same data)?
- Can my team invest 3 to 6 months learning event sourcing?
- Can my ops team monitor and maintain an event store?
If every answer is yes, event sourcing makes sense. If even one is no, reconsider.
Event store technologies
If you do go for it:
EventStoreDB: purpose-built for event sourcing. Mature, feature-rich.
Kafka: a log-as-event-store. But you need to build on top for real event-sourcing features (snapshots, projections).
PostgreSQL append-only table: enough to start with. It scales to a billion events. You can move to a specialised tool later.
Marten (on PostgreSQL): an event-sourcing library for the .NET world. Uses PostgreSQL as the event store.
Start small. PostgreSQL plus your own snapshot logic. Upgrade when the need is real.
Takeaway
Event sourcing is powerful but has a narrow use case. Financial systems, complex workflows, collaborative tools. For general-purpose web apps it’s overkill.
The hybrid approach (current state + event audit log) gives you 80% of the benefit at 30% of the complexity. Start there, and move to full event sourcing if a real need appears.
Not every pattern loud at technical conferences is right for your project. Understand the problem first, pick the solution second.