Event Sourcing and CQRS: The Ledger-Style Design Decision That Tells You How Your Data Got Here (And When It Is Not Worth the Cost)

Your finance lead asks a simple question: "Why did this customer's balance change last Tuesday?" Your database shows the current number and nothing else, because every update overwrote the one before it. Your team spends two days reconstructing the answer from logs, backups and memory. At AEGONTECH LLC we see this scenario in client audits more often than almost any other, and it is rarely a bug. It is a design decision: the system stores what is true now and throws away how it got there.

Event sourcing and CQRS are the two patterns that reverse that decision. They are also among the most over-adopted patterns in software, so this article covers when they pay off and when they quietly drain a team's budget.

Key Takeaways

• Event sourcing stores every state change as an immutable event instead of overwriting the current state, giving you a complete audit trail for free.
• CQRS (Command Query Responsibility Segregation) separates the model that handles writes from the model that serves reads, so each can be optimized independently.
• The two patterns are independent: you can use CQRS without event sourcing, and for most teams that is the right first step.
• Adopt event sourcing only where history is a business requirement (finance, compliance, ordering, inventory), not as a default architecture.
• The real cost is not the code, it is event schema evolution and operational discipline over the following years.

What Is Event Sourcing, and How Is It Different From a Normal Database?

Event sourcing is a pattern where the source of truth is an append-only log of events, such as OrderPlaced, PaymentCaptured or AddressChanged, rather than a table row holding the latest values. The current state is derived by replaying those events in order.

In a conventional CRUD (create, read, update, delete) design, an update statement replaces the old value. The previous state is gone unless you built separate audit tables. In an event-sourced design, nothing is ever overwritten. A bank account is the classic example: the balance is not stored, it is the sum of every deposit and withdrawal. Accountants have worked this way for centuries, which is why the pattern fits financial software so naturally.

A good rule of thumb from our engineering practice: if your business already thinks in terms of a ledger, your software should too.

What Is CQRS, and Why Pair It With Event Sourcing?

CQRS stands for Command Query Responsibility Segregation. A command changes state ("place this order"); a query reads state ("show me my orders"). CQRS says these two jobs get separate models, and often separate data stores.

The reason is that reads and writes have opposite needs. Writes need strict validation and consistency. Reads need speed and shape: a dashboard might need data joined from six aggregates in a single fast lookup. Forcing one model to serve both produces compromises on both sides. Industry experience suggests that most production systems serve far more reads than writes, often by a factor of 10 to 100, so letting the read side scale and be shaped independently is a real advantage.

Event sourcing and CQRS pair well because the event log is a natural write model, and read models ("projections") are built by subscribing to those events. A PostgreSQL table, an Elasticsearch index and a Redis cache can each be a projection of the same event stream, each shaped for its own query pattern.

When Does Event Sourcing Actually Pay Off?

Event sourcing pays off when the history itself has business value. In our experience, four situations justify the cost:

1. Regulatory and audit demands. Frameworks such as SOC 2 and financial regulations require you to show who changed what and when. An event log answers this by construction rather than by bolted-on logging.
2. Temporal questions. "What did this customer's cart look like when they complained?" is trivial with events and nearly impossible with overwritten rows.
3. Complex domain workflows. Order fulfilment, claims processing and booking systems have long lifecycles where every transition matters.
4. Debugging production. Replaying the exact event sequence that produced a bad state turns a vague bug report into a reproducible test case.

Teams that adopt event sourcing in these areas commonly report that investigation time for data-integrity incidents drops from days to hours, because the evidence is already in the log. Treat that as an indicative range, not a guarantee, but the mechanism is sound.

When Should You Avoid Event Sourcing?

Avoid it when your data is simple, your history has no business value, or your team has not run it before. A settings page, a content management screen or a user profile rarely benefits. Event sourcing is not an architecture, it is a tool for specific bounded areas of a system. Applying it everywhere multiplies complexity without multiplying value.

Compare the two honestly. CRUD is easy to hire for, easy to debug with a SQL client, and well supported by every ORM (object-relational mapper). Event sourcing demands that every engineer understand eventual consistency, projection rebuilds and event versioning. We often advise clients to start with CQRS on a single PostgreSQL database, separating read views from write logic, and to introduce event sourcing only inside the one bounded context that truly needs it.

What Are the Hidden Costs Nobody Mentions in the Conference Talk?

The first hidden cost is eventual consistency: after a command succeeds, the read model may lag by milliseconds or seconds. A user who saves a change and immediately sees the old value will file a bug report. Good designs handle this explicitly, for example by returning the new state from the command response or by reading from the write side right after a write.

The second is event schema evolution. Events are immutable and live forever, but your understanding of the business changes. A CustomerRegistered event from 2024 will have fewer fields than one from 2026. You need versioning and "upcasting" (translating old events to the current shape on read) from day one. Teams that skip this discover the problem around month eighteen, when it is expensive.

The third is operational maturity. Rebuilding a projection from 50 million events can take hours. You need monitoring on projection lag, a replay strategy, and snapshots (periodic saved states that avoid replaying the full history). If you are still building out observability, fix that first.

The fourth is the deletion problem. Immutable logs collide with the GDPR right to erasure. The usual answer is to keep personal data out of events, store it in a separate keyed store, and delete the key ("crypto-shredding"). Decide this before the first event is written.

How Do You Introduce These Patterns Safely?

Introduce them incrementally, in one bounded context, behind a clear boundary. A sequence that has worked for AEGONTECH clients:

• Step 1: Model the domain events on paper. If your domain experts cannot name the events in plain language, the area is not ready.
• Step 2: Separate commands from queries in code using ordinary application services, still on one database.
• Step 3: Add an outbox. Write events to a table in the same transaction as the state change, then publish them reliably. This avoids the dual-write bug where the database commits but the message is lost.
• Step 4: Build one read projection and measure its lag before adding more.
• Step 5: Only then consider making events the source of truth, using a purpose-built store or PostgreSQL with an append-only table.

This is the same discipline we apply in our own products. On platforms like Dolfy.ai and Mimicall.app, where usage records and billing events must be traceable, an event-style ledger for the few entities that need it, with conventional tables everywhere else, has kept the system understandable for a small team.

Event Sourcing vs Traditional State Storage: A Quick Comparison

| Concern | Traditional CRUD | Event Sourcing + CQRS | |---|---|---| | Audit trail | Extra tables, easily incomplete | Built in, complete | | Read performance | One model, compromises | Tailored projections | | Complexity | Low | High | | Schema changes | Migrations | Event versioning | | Hiring and onboarding | Easy | Specialist knowledge helps | | Best fit | Most applications | Ledger-like, regulated domains |

The table is a reminder that the right answer is almost never "everywhere" and rarely "nowhere." It is "in the places where history is money."

Frequently Asked Questions

Do I need event sourcing to use CQRS?

No. CQRS only requires separate read and write models. Many teams run it on a single relational database with views or denormalized read tables and never store events at all. It is the lower-risk way to gain most of the benefit.

Is event sourcing the same as event-driven architecture?

No. Event-driven architecture is about services communicating through events. Event sourcing is about using events as the storage mechanism inside one service. You can have either without the other, although they combine well.

How long does it take to rebuild a projection?

It depends on event volume and projection complexity. Millions of events typically take minutes to hours. Snapshots and parallel replay reduce this, and you should test a full rebuild before going live, not during an incident.

Can I add event sourcing to an existing system?

Yes, but carefully. Start with one bounded context, publish events through an outbox, and keep the old tables as the system of record until the new path is proven. A big-bang conversion is where these projects fail.

Conclusion

Event sourcing and CQRS are powerful when history is part of the product, and an expensive distraction when it is not. The most useful question to ask is not "is this modern?" but "who will need to know how this value came to be, and when?" If the answer is auditors, finance teams or support staff, a ledger-style design earns its keep.

If you are weighing these patterns for a real system, the engineers at AEGONTECH LLC are happy to review your domain with you and tell you honestly whether you need them. You can reach us through aegontech.dev to arrange a consultation.