I recently read Gunnar Morlingâs article (https://www.morling.dev/blog/you-gotta-push-if-you-wanna-pull/) about change data capture and push-based queries. As I worked through it, I couldnât shake a thought: he is basically describing Event Sourcing, without mentioning Event Sourcing. Heâs describing exactly what most teams would love to have - reactive systems, event-driven flows, derived views. Yet many of these same teams will tell in the same sentence, that Event Sourcing is âtoo complex.â
Thereâs a fascinating paradox here. Teams willingly embrace CDCâs - setting up Debezium, managing Kafka connectors, dealing with schema evolution in CDC streams - but simultaneously reject Event Sourcing as too complicated. Whatâs really going on?
The Familiarity Trap
I think it comes down to something simpler than complexity: familiarity. Capturing changes from a relational database still feels like known territory. Youâre working with tables, columns, primary keys - the mental models developers have used for years.
I often hear people argue that CDC is âbetter Event Sourcingâ because people donât have to learn a new paradigm. But hereâs the problem: learning the new paradigm - or better yet, unlearning the old one - is exactly what makes it work.
The distinction is fundamental. What Gunnar describes is deriving changes from state. Event Sourcing is deriving state from changes. CDC reverse-engineers events from state mutations. With Event Sourcing, the events ARE the source of truth, and state is just a projection.
The Mental Shift That Changes Everything
State-based thinking asks: âWhat is the state?â Event-based thinking asks: âWhat happened?â
The moment I truly understood Event Sourcing, there was no going back. When youâve captured all those state changes as first-class events, youâre free to do whatever you want with them. Itâs fascinating - the possibilities unfold in ways that simply arenât available when youâre locked into state-first thinking.
Hereâs whatâs interesting: even if your implementation remains state-based, thinking in events is always beneficial. It captures system behavior much more clearly. You see what actually happens in your domain, the facts, the flow of time.
But if event-based thinking is valuable even without Event Sourcing implementation, why push teams to go all the way? Why not just say âthink in events, model in events, but store stateâ - which is essentially what CDC gives you?
The Missing Piece: Intent
CDC gets you halfway there. You capture the changes, you can materialize views, you can precalculate things. But you lose something critical: intent.
CDC gives you âwhat changed.â Event Sourcing gives you âwhy it changedâ - the business intent behind the change. That intent is where true flexibility lives.
Let me give you a concrete example. We use CDC extensively in integration scenarios - itâs not a bad tool at all. Actually itâs crucial for integration.
But sometimes it makes people do crazy things. In one project where Event Sourcing didnât play any role (forbidden by Enterprise Architecture - Event Sourcing is not part of the Blue Print), we used CDC to capture changes to a customers table. We had the state deltas, we knew fields had changed, but we didnât know why.
So what did we do? We built custom âintent checkâ logic that analyzed the incoming change against the current state to rediscover the business event. Come on, I know you are doing this as well.. admit it. We were comparing deltas, looking at which fields changed together, trying to reverse-engineer: âWas this a customer upgrade? A correction? A cancellation?â
Think about that for a moment. We threw away the intent, then built custom logic to guess at what it might have been. We were doing âpoor manâs Event Sourcingâ - building the hardest parts ourselves, just badly.
And hereâs the thing: this is what most teams do. They avoid Event Sourcing because it requires radically different thinking. They stick with what feels familiar, even when that means recreating Event Sourcing piece by piece, without the benefits that come from embracing the paradigm fully.
Why the Resistance?
When I work with teams, the resistance isnât really technical. Itâs a people problem. If you truly apply Event Sourcing, itâs radically - really radically - different from what youâve been doing for years.
You only focus on what happens in the system, the facts. You donât think in state. That shift feels wrong to experienced developers. Their instincts, built over years of CRUD applications and normalized databases, push back hard.
Some team members get it, get excited about the possibilities. But the majority isnât ready. They need to change their thinking, and thatâs the really hard part. Itâs not about learning new technology - itâs about rewiring fundamental assumptions about how systems work.
The Question You Should Ask
Look, CDC has its place - itâs crucial for integration. But itâs often misused as poor manâs Event Sourcing.
If youâre already doing CDC, look closely at what youâre building on top of it. Are you writing logic to figure out business intent from state changes? Are you reconstructing the âwhyâ from the âwhatâ? Are you building sophisticated change analysis to understand what actually happened?
If so, youâre already doing Event Sourcing. Youâre just doing it the hard way, without the tooling, patterns, and clarity that come from embracing it directly.
The real complexity isnât Event Sourcing. The real complexity is pretending you donât need it while recreating it badly, one custom integration at a time.
CDC is what you do when youâre not allowed to use Event Sourcing. But maybe itâs time to ask: whoâs not allowing it? And what are they actually protecting you from - complexity, or just unfamiliarity?
Martin Dilger is the founder of Nebulit and a recognized expert in Event Modeling and event-driven architectures. He helps teams cut through project chaos by bringing clarity to complex systems.
Your team works with CDC, Kafka and streaming technologies and you have the feeling itâs not running smoothly? You feel thereâs a lack of know-how and experience? Maybe we can help. Learn more now. You can also place some technical questions here.
Join the Agentic Engineer Program
Apply Spec-Driven Development Hands-On - Event Modeling, Event Sourcing, and AI Engineering with autonomous agents.
Book a Call Today
Want to talk through how Event Modeling could work for your team or project? Letâs have a quick, no-pressure conversation.