What this prompt does
This prompt frames the model as a data engineer who has run change data capture in production and asks for real configs and a clear flow, not a high-level overview. You supply [warehouse], [tables], and [lag_tolerance], and it returns Postgres replication setup, a Debezium connector config, schema-evolution handling, a backfill strategy, a dead-letter queue, and lag monitoring.
The structure works because CDC fails at its boundaries, and the prompt names them. [tables] scopes the publication and the connector's table filter so you only capture what matters. [lag_tolerance] drives the monitoring thresholds -- alerts fire against your stated SLA, not an arbitrary number. The backfill deliverable specifically reconciles history without double-counting live changes, and the dead-letter queue catches poison events instead of stalling the stream. By making slot hygiene and lag alerts first-class deliverables, the prompt addresses the failures that quietly fill disks or break connectors instead of treating them as afterthoughts.
When to use it
- You're replicating Postgres into a warehouse and want CDC done with production-grade configs.
- You need
wal_level, a replication slot, and a publication set up correctly for specific tables. - A schema change broke a connector before and you want evolution handling written in.
- You need a backfill that reconciles history without double-counting live rows.
- You want a dead-letter queue for un-deserializable or poison events.
- You need lag and connector-failure alerts tied to a concrete tolerance, not a guess.
- You need the initial snapshot mode chosen so a large backfill doesn't block live capture.
Example output
You get the Postgres configuration (wal_level, slot, publication), the Debezium connector config with snapshot mode and table filter, the schema-evolution and backfill notes, the dead-letter-queue setup, and an ASCII flow diagram of the whole pipeline. It reads like a runbook with real config blocks you can paste and adjust, not a conceptual diagram you still have to translate into working connectors.
Pro tips
- List exactly the
[tables]in scope (orders, payments, refunds) so the publication and connector filter stay tight. - Set
[lag_tolerance]to your real SLA (under 60 seconds) so the monitoring thresholds match what downstream actually needs. - Make
[warehouse]specific (e.g.Snowflake via Snowpipe) because the load and merge mechanics differ by destination. - Watch the replication slot size for a week before trusting it unattended -- an un-cleaned slot can fill the disk silently.
- Ask the model to detail what happens when a column is added, dropped, or retyped so a schema change can't break the connector unnoticed.
- Confirm the backfill plan reconciles against live changes; double-counting is the classic CDC backfill bug.
- Pick a snapshot mode in the Debezium config that fits your
[tables]size so the initial snapshot doesn't stall live capture.
