Event sourcing for business software explained in plain terms: instead of storing only the current state of a record, you store every meaningful thing that happened to it, in order, as an append-only log — and rebuild current state by replaying that log whenever you need it. If your business system ever has to answer not just “what is the balance?” but “how did it get here, who changed it, and what did it look like last Tuesday?”, that difference matters more than any framework choice you will make this year. This guide covers what event sourcing is, where it earns its keep, what it costs in real projects, and how to tell whether your system needs it — or whether plain CRUD is still the right call.
It is written for business owners and technical leads weighing an architecture decision. By the end you will be able to spot where an event log pays for itself, where it would be an expensive hobby, and how to pilot it safely.
What event sourcing actually is
Most business software uses CRUD: create, read, update, delete. An order row sits in a database table, and every change overwrites it — a changed delivery address erases the old one, and a removed discount leaves only the final state. Fine for a brochure site or a settings page; a problem the first time someone asks a question about the past.
Event sourcing flips the model: the event log is the source of truth, and current state is derived from it. An order lives not as one mutable row but as a stream of facts — OrderPlaced, PaymentCaptured, ItemShipped, RefundIssued — each immutable and timestamped. To find the order’s current state, replay its events in sequence. Nothing is ever overwritten, so nothing about the journey is ever lost.
Think of a bank balance versus a bank statement. The balance tells you where you stand; the statement tells you how you got there — and it is the statement an auditor, a regulator, or an unhappy customer actually wants. A recent practical guide makes the same point: CRUD overwrites data, while event sourcing stores every event that ever happened and derives state by replaying them (see Event Sourcing Explained: When CRUD Is Not Enough).
Event sourcing for business software explained: the moving parts
Four pieces make the pattern work.
The event store
The event store is an append-only log: new events go to the end, old ones are never updated or deleted. Each event belongs to one stream — usually one business entity, such as one order — and carries a version number so concurrent writers cannot silently overwrite each other. The append-only rule is non-negotiable: break it and you lose the one property the whole pattern exists to provide.
Aggregates and commands
Business rules live in aggregates. A command such as “ship this order” arrives, the aggregate loads its past events, checks the rules (paid? already shipped?), and either rejects the command or emits new events. Validation happens before the event is written, because an event states that something already happened. A common beginner mistake is putting business logic in event handlers instead of the aggregate; handlers should react to facts, not decide them.
Projections and read models
Replaying thousands of events on every page load would be slow, so event-sourced systems build projections: read models derived from the log, stored in whatever shape each screen or report needs. Here is the pattern’s killer feature: if a projection has a bug, or the business invents an unanticipated report, you rebuild it by replaying the log from the start — no backfill scripts, no data migration, no “we didn’t capture that field in 2023.”
CQRS, the usual travelling companion
Event sourcing is often paired with CQRS, which separates the write path (commands, validation, events) from the read path (projections, queries). The two are independent, but they fit together because writes need consistency and rules while reads need speed and flexible shapes. One clear-eyed analysis warns that most teams underestimate the operational cost of running both — the cost-benefit analysis should come before adoption, not after (see CQRS and Event Sourcing: When the Complexity Is Worth It).
Where an event log earns its keep
Event sourcing is not a better database. It is a better answer to a specific set of questions, and it earns its keep when one or more of these are true for a bounded part of your system:
- Regulatory or contractual audit trails. Finance, healthcare, and any business that must prove who did what and when. An append-only log is an audit trail by construction, not a feature bolted on afterwards.
- Temporal questions. “What did this customer’s entitlements look like on 5 March?” With CRUD you need snapshot tables and luck; with an event log you replay to a point in time.
- Disputes and debugging. A customer disputes a charge from three months ago, or support must explain why an order took a strange path. The log shows the sequence of facts, not just the end state.
- Multiple read models from one truth. A finance report, a warehouse pick list, and a customer timeline all derived from the same order stream, each rebuilt independently.
- Approval and undo workflows. Multi-step processes where steps can be reviewed, reversed, or compensated. Events map onto business steps in a way status columns never quite do.
The real costs nobody puts in the demo
This is the section most introductions skip, and it decides real projects. Event sourcing is genuinely more expensive to build and run than CRUD, in at least five ways.
Schema evolution is forever
In a CRUD system, a changed requirement means a migration: alter the table and move on. In an event-sourced system, events written three years ago in version 1 format must still be readable by code deployed today, because the log is immutable. The standard answer is upcasting — transforming old event versions into current ones as they are read — but that means maintaining a migration layer for every event type ever shipped. Teams that skip this end up with events nobody can replay, which is worse than having no log at all.
Eventual consistency is a user-experience decision
Projections update after events are written, usually asynchronously. A dashboard half a second behind is fine; a customer who just paid and still sees “unpaid” is a support ticket. Every screen reading a projection needs a decision about how fresh it must be — design work CRUD never asked you to do.
Replay is powerful and dangerous
Rebuilding a projection replays the whole stream. For a long-lived aggregate with tens of thousands of events, that is slow unless you snapshot state periodically — say every hundred events — and replay only from the last snapshot.
Privacy law collides with immutability
A customer exercising their right to erasure does not care that your architecture treats events as forever. The practical answers — encrypting personal data in events and destroying the key (crypto-shredding), or keeping personal data out of events and referencing it by ID — must be designed in from day one. This alone is a reason to scope event sourcing to bounded contexts.
Your team has to learn a new mental model
Developers think in current state by default. Event modelling — naming events as past-tense domain facts (OrderShipped, not OrderStatusUpdated), drawing aggregate boundaries, reasoning about eventual consistency — takes months to build across a team. A CRUD service taking two weeks takes meaningfully longer event-sourced, mostly learning and operational plumbing, not typing.
From our experience: the hybrid answer is usually right
Across 9+ years and 300+ projects at MTD Technologies, we see event sourcing work best as a tactical choice inside one bounded context, not a company-wide religion. Order and payment flows get an event log, because money and disputes live there. User profiles, feature flags, and static settings stay on CRUD tables — nobody has ever asked what a feature flag looked like in March.
Three gotchas from real builds are worth naming. First, granularity: a generic FieldUpdated event is just CRUD wearing a costume — events must express domain intent, or the log teaches you nothing. Second, dual writes: never write to the event store and a separate table in two uncoordinated steps; use a transactional outbox or a single write path, or the two will drift. Third, resist event-sourcing the prototype: if the domain model changes every few days, maintaining upcasters will slow you to a crawl. Build CRUD first; introduce an event log once its events are stable facts, not guesses.
Getting started without betting the company
If the case is real for one part of your system, pilot it narrowly:
- Step 1: Pick one bounded context. One aggregate with clear audit or temporal value — orders, subscriptions, or payments — and a team that will own it.
- Step 2: Model the events with the business, not just developers. Sit with the people who handle disputes and audits and name the events they actually ask about. If the business cannot name ten meaningful events, the context is not a fit.
- Step 3: Keep personal data out of events. Reference customer data by ID and resolve it at projection time, so erasure requests stay solvable.
- Step 4: Build one projection and one replay path first. Prove you can rebuild a read model from scratch before building five of them.
- Step 5: Decide your consistency story per screen. List which screens must be immediately consistent and design those reads explicitly, rather than discovering the gap via a customer complaint.
- Step 6: Measure the overhead honestly for a quarter. Compare build time, incident time, and replay time against the CRUD equivalent, and expand only if the audit and debugging savings show up in real tickets, not just in theory.
If you need help making that call, our custom software and API development team works through these trade-offs with clients before writing code — including telling them when the honest answer is “stay on CRUD.” To talk through your specific system, contact us and describe the part of the business that keeps asking questions about the past.
Frequently asked questions
Is event sourcing the same as CQRS?
No. Event sourcing is about how you persist state — as a log of events rather than current state. CQRS separates the write model from the read model. They are often used together, but each works alone, and adopting both at once roughly doubles the new concepts your team must learn.
Does event sourcing replace my database?
No. The event store is the source of truth, but applications still read from projections stored in ordinary databases. Most production systems end up with both: an append-only log plus several read-optimised stores built from it.
When should a small business not use event sourcing?
When the domain is simple, audit requirements are light, the team is small, or the product is still finding its shape. A blog, a brochure site, or an early-stage prototype gets almost nothing from an event log and pays all of its costs. Start with CRUD, and revisit the decision when real audit or temporal questions start arriving.
How do you handle GDPR deletion with an immutable log?
Either keep personal data out of events (events reference entities by ID, with personal details in a deletable store resolved at projection time), or encrypt personal data inside events and destroy the key on erasure — crypto-shredding. Either must be designed in before launch; neither is easy to retrofit.
The bottom line
Event sourcing for business software explained honestly comes down to one question: does your business regularly need to know not just what is true now, but how it became true? If yes for a specific part of your system — money movement, regulated records, disputed orders — an event log is worth its costs. If no, CRUD is not old-fashioned; it is the right tool, and the money saved can go into features customers will notice. The best architecture decision is rarely the most fashionable one. It is the one whose costs you understand before you commit.