You have a service. It writes to its database and it publishes to a queue — and you have been bitten (or nearly bitten) by the gap between those two writes. The database commit succeeded but the queue publish failed; the publish ack got lost so a retry duplicated the event; two writers raced and the queue's order disagreed with the database's last-writer-wins. Each is a permanent inconsistency: a state the system cannot heal on its own, because the system is two systems with no shared atomicity boundary.

This curriculum is about closing that gap. The fix is Change Data Capture — turning the database's own write log into a stream of change events — and the engineering pattern that makes it land in production: the outbox pattern, where every business write also writes a row whose entire purpose is to be published. Modeled on Debezium and Postgres logical replication.

You start from the user's mental model. "I have a service that writes to its DB. I want other services to know about my changes without breaking my service." From that one frame, every concept arrives motivated: the WAL exists because the database needs it for recovery; the replication slot exists because the database needs to know how far the consumer has read; the snapshot exists because the WAL doesn't go back forever; the outbox exists because the service still wants atomicity. Eleven scenes plus a capstone, no slideshow.

The single insight that unlocks the design: the database's own write log is the source of truth your downstream consumers wanted all along — the outbox makes that source carry your domain events instead of your row deltas.