A Row Change Isn't a Business Event

Change data capture will hand you a stream of rows that changed, timestamped and ordered, the moment they change. That sounds like real-time intelligence. It isn't, yet — it's real-time plumbing. A row update on an orders table doesn't tell you a customer just churned, a shipment is late, or a margin just went negative on a product line. Someone still has to translate "this row changed" into "this business fact occurred." Skip that translation and your real-time system is very fast at delivering information nobody can act on.

The gap between CDC and meaning

CDC answers "what changed." A business event answers "what happened, in terms a person making a decision would recognize." Those are different questions, and the difference is exactly the modeling work that makes real-time systems useful instead of just fast:

• A CDC row: status changed from 3 to 7 on orders row 48213.
• A business event: order shipped late, for a customer in a segment where late shipments predict churn.

The first is a fact about a database. The second is a fact about the business. Building the second out of the first is a declaration of intent — someone has to decide, in advance, which state transitions matter and what they mean.

Why this keeps stalling out

Teams that skip this step usually do so for a reasonable reason: it's more work up front, and a raw CDC feed feels like progress you can ship today. But a stream of undifferentiated row changes doesn't compound — every consumer has to re-derive "what does this change mean" for themselves, the same interpretation logic scattered across every downstream system that touches the feed. That's the exact failure mode conformed dimensions were invented to prevent, just moved into the streaming layer instead of the warehouse.

Declare the event, not just the schema

The fix is the same discipline that makes batch models trustworthy, applied one layer earlier: define the business event once — its trigger condition, its grain, its meaning — in a governed place, and let every consumer subscribe to that, not to the raw change feed. "VIP churn risk" or "margin breach" should be a first-class, versioned definition with an owner, not a filter condition copy-pasted into five different stream processors that will drift from each other within a quarter.

What good looks like

A mature real-time architecture has a thin, fast layer that captures change (CDC does this well — leave it alone) and a distinct, governed layer that turns changes into named business events with agreed-on meaning. The first layer is infrastructure. The second layer is where the actual value lives, and it's modeling work, not plumbing work — which means it deserves the same rigor you'd give a fact table: one grain, one definition, one place it's declared.

Start with the one CDC feed your team already argues about the meaning of. Write down its trigger condition, its grain, and its meaning — in one governed place, with one owner — instead of leaving each downstream consumer to guess. Real-time isn't valuable because it's fast. It's valuable when what arrives quickly is also something a person can trust and act on the moment it lands.