About

Methodology

How content gets researched, how claims are checked, and what happens when something turns out to be wrong. The short version: the site is open-source, the editorial workflow is in the public Git history, every module page tells you exactly when it was last reviewed, and every page links to its own source file.

Who writes this

Let's Talk CDC is written and maintained by Christopher Ennis. Author of CDC: The Missing Manual. Writes about change data capture, streaming data, and what actually breaks in production.

There is no marketing department, no vendor sponsorship, and no SEO content farm behind the byline. If you find a claim that smells like one of those, please open an issue — that's a bug.

Vendor-neutral by default

Modules introduce concepts first (snapshots, log retention, exactly-once, schema evolution) and only then map them onto specific tools (Postgres, MySQL, SQL Server, Oracle; Debezium, Kafka Connect, Fivetran, Matillion). When a vendor-specific quirk has to be called out — Postgres replication slots, MySQL binlog_row_image, Oracle UNDO retention — we name the vendor and link to the upstream docs.

The Tooling module and Changelog & Version Matrix are the only places where vendor names lead. Everywhere else the goal is to teach the underlying primitive so a reader can map it to whatever stack lands in front of them next year.

How claims get verified

Three pipelines guard against the most common ways an educational page rots in public:

External links: lychee runs on every push via linkcheck.yml. When a vendor moves a docs page, the build goes red and the stale URL is updated in the citing module (recent examples: Debezium's signalling.html rename, Fivetran's changelog path drift, Matillion's docs-subdomain move).
Page health: Lighthouse CI runs on every push via ci.yml with error-level performance and accessibility thresholds on /intro/ (perf ≥ 0.82, a11y ≥ 0.93) and warn-level thresholds across all sampled URLs. The thresholds are honest baselines — when the LHCI test harness was discovered to be serving an unstyled DOM, the previous "1.0" scores were retracted publicly in the changelog and replaced with what the styled page actually measures.
Build + smoke: npm run verify-all is the minimum bar before any change merges: format check, ESLint, 274+ unit tests (vitest), full Eleventy + Vite production build. npm run smoke:core asserts that critical pages render, CSP headers stay hardened, the per-page "Edit this page on GitHub" link is well-formed, and the inline errata callouts only appear on the pages they were tagged to.

Freshness signals

Every module page renders a "Last reviewed" stamp in its footer aside, derived from the page's dateModified front-matter. When the date and the page diverge enough that a reader should know something changed, the stamp gets bumped in the same commit. The RSS feed sorts by dateModified so feed readers see substantive revisions, not just first-publish dates.

Tool versions for the things we benchmark (Postgres, MySQL, Debezium, Kafka Connect, Confluent Cloud, AWS DMS, Fivetran, Matillion) live in src/_data/toolVersions.mjs and surface inline on the Version Matrix page so a reader can see at a glance how current we're claiming to be.

When we're wrong

Two places to look:

The errata hub at /errata/ — a living list of the precise clarifications, sharp edges, and "this wasn't quite right" notes that come out of reader feedback.
Inline errata callouts on individual module pages — when a correction applies to a specific page, a collapsed "Known errata for this page" disclosure appears at the top of that page so a reader doesn't have to know the errata hub exists to see it.

Spotted something wrong? The fastest path is the "Edit this page on GitHub" link in every page footer — it opens the page source directly in the GitHub editor. Or open an issue.

Open source, audit-friendly

Every page, every diagram, every dataset, every CI configuration, every test, and this methodology page itself are public at github.com/sandgraal/letstalkcdc. Run the site locally with npm ci && npm run dev; walk the build pipeline in CLAUDE.md; read the running roadmap in docs/IMPLEMENTATION-PLAN.md to see what's planned and what's done.

The CHANGELOG is the running scratchpad for the current dev cycle — it tracks what shipped, when, and why, in human-readable sentences rather than commit-message shorthand.

What this isn't

Not a vendor benchmark. We don't run head-to-head throughput tests; numbers in the Tooling and Version Matrix pages cite upstream documentation and clearly attribute claims back to their source.
Not a replacement for the official docs. Where a vendor's documentation is good (Debezium's connector reference, Postgres's logical decoding chapter), we link to it and resist the urge to paraphrase. Where it's confusing or out of date, we say so and link anyway.
Not consulting advice. The modules are an educational starting point. A real production CDC pipeline has constraints (latency budgets, schema-change cadence, regulatory holds, sink semantics) that no static page can account for.