The Log Never Lies: Change Data Capture with Debezium
Your service saved the row, then the pod died before the Kafka send. A three-part field guide to change data capture for Java developers: read the database's own log instead of trusting your code to remember, with PostgreSQL, Debezium, Kafka and Spring Boot, and the replication-slot habits that keep the disk from filling up at 3 a.m.
"The Dual-Write Trap" — CDC from First Principles
A deploy kills pods between the commit and the Kafka send, and Dispatchly's customers never hear their parcel is out for delivery. Zoya learns why "save, then publish" cannot be made safe, why polling updated_at quietly loses data, and how PostgreSQL's write-ahead log, logical decoding and replication slots make the database itself the source of events. No pipeline yet: we read the log by hand.
"Plugging Into the WAL" — Kafka Connect, Debezium and Postgres, End to End
Zoya builds the pipeline: Kafka Connect from the ground up, a least-privilege Debezium connector on PostgreSQL 18, real change events (deletes, key changes, TOAST placeholders, decimals), and a Spring Boot 4.1 projection that stays correct when a killed Connect worker replays everything. Plus the failures you will meet, provoked on purpose.
"Production Without Prayers" — Outbox, Snapshots, Slots and Schemas
Tomás runs a game day. Zoya replaces the last dual write with a transactional outbox, backfills a table with an incremental snapshot, lets a quiet database pin WAL until a slot is invalidated, breaks a schema on purpose, kills Connect workers, and turns on exactly-once, with the measurements, the misleading log lines and the production checklist that came out of it.