Home
ArenaGraphSignalTopics
/Apache Kafka and Event-Driven Systems: Building Real-Time Streaming Pipelines
Chapter 8 • Module 1 8 min breakdown +15 XP Module

What is Change Data Capture (CDC)? Query Polling vs Log-Based Replication

From Track:Apache Kafka and Event-Driven Systems: Building Real-Time Streaming PipelinesEvent-Driven Architecture & Distributed Systems

In modern distributed software systems, the database is no longer a static silo where data goes to rest. It is a live stream of state transitions that must continuously synchronize with search engines (Elasticsearch), caches (Redis), analytics warehouses (Snowflake, BigQuery), and downstream microservices.

Historically, organizations attempted this synchronization by repeatedly querying tables using Polling. Today, the industry standard is Log-Based Change Data Capture (CDC) powered by tools like Debezium.


1. The Breakdown of Query-Based Polling

In a polling architecture, a scheduled cron job periodically runs SQL queries such as:

sql
Loading code editor...
Interactive Blueprint
Rendering diagram...

The Intermediate Update Blindspot:

If an order changes state twice between consecutive polling cycles ():

  1. : Order state changes from PENDING PROCESSING.
  2. : Order state changes from PROCESSING SHIPPED.
  3. (Next Poll): The query extracts only the final SHIPPED state. The PROCESSING domain transition is permanently lost, breaking state machine audit logs and analytics.

2. Log-Based Change Data Capture (CDC) Architecture

Instead of issuing SQL queries against the relational query engine, Log-Based CDC hooks directly into the database engine's low-level Write-Ahead Log (WAL) (e.g., PostgreSQL WAL, MySQL Binlog, Oracle Redo Log):

Interactive Blueprint
Rendering diagram...

3. Detailed Architectural Comparison

DimensionQuery-Based PollingLog-Based CDC (Debezium)
Performance OverheadHigh (Table locks, CPU spikes, index churn)Near Zero (Reads append-only WAL stream)
LatencyHigh ()Sub-millisecond ()
Intermediate UpdatesLost (Only captures latest snapshot)100% Captured in strict commit order
Hard Deletes DetectionImpossible without Soft-Delete flagsNatively captured via WAL tombstone markers
Application Code ChangesRequires updated_at columns & triggersZero code modifications required
Transaction BoundariesLostPreserved (Atomicity retained)

4. Debezium Event Envelope Anatomy

A Debezium CDC event published to Kafka contains both the Before State, After State, and comprehensive database transaction metadata:

json
Loading code editor...

Key Envelope Attributes:

  • op (Operation Type):
    • 'c': Create (INSERT)
    • 'u': Update (UPDATE)
    • 'd': Delete (DELETE)
    • 'r': Read (Initial snapshot)
  • before / after: Exact structural diff of the database row before and after the transaction committed.
  • lsn (Log Sequence Number): Monotonically increasing pointer in the PostgreSQL WAL, guaranteeing exact position tracking.

5. Summary & Key Takeaways

  1. Retire Query Polling: Polling databases for changes is an antipattern that wastes database compute and misses critical intermediate transitions.
  2. Log-Based CDC is Non-Invasive: Because Debezium reads WAL logs asynchronously, it operates without acquiring table locks or adding latency to application transactions.
  3. Foundation for Event-Driven Architecture: CDC provides a safe bridge to extract events from legacy monolithic databases into Apache Kafka without rewriting legacy applications.
Milestone Verification

Ready for the next lesson?

Mark this module complete to record verified progress and earn +15 XP toward your architect profile.