<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>CDC on gywn&#39;s tech</title>
    <link>/en/tags/cdc/</link>
    <description>Recent content in CDC on gywn&#39;s tech</description>
    <generator>Hugo</generator>
    <language>en</language>
    <managingEditor>gywndi@gmail.com (gywndi)</managingEditor>
    <webMaster>gywndi@gmail.com (gywndi)</webMaster>
    <lastBuildDate>Sun, 23 Aug 2026 23:31:52 +0900</lastBuildDate>
    <atom:link href="/en/tags/cdc/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Debezium Only Captures - Verifying Source Swapping and Parallel Processing in Practice</title>
      <link>/en/2026/08/embedded-debezium-parallel-pipeline/</link>
      <pubDate>Sun, 23 Aug 2026 22:30:49 +0900</pubDate><author>gywndi@gmail.com (gywndi)</author>
      <guid>/en/2026/08/embedded-debezium-parallel-pipeline/</guid>
      <description>&lt;h2 id=&#34;previous-post-recap&#34;&gt;Previous Post Recap&lt;/h2&gt;&#xA;&lt;p&gt;In the &lt;a href=&#34;/en/2026/08/debezium-smt-cant-parallelize/&#34;&gt;previous post&lt;/a&gt;, I confirmed that splitting the Debezium embedded engine&amp;rsquo;s callback into a submit thread (TRD1) and an order-preserving drain thread (TRD2) lets you process in parallel with no performance loss (98-101%) while still preserving order. But that was a pure benchmark - just a single id pulled out, queued, and checked for order.&lt;/p&gt;&#xA;&lt;p&gt;This post set out to build two things.&lt;/p&gt;&#xA;&lt;ol&gt;&#xA;&lt;li&gt;&lt;strong&gt;Can you swap MySQL for Postgres without changing a single line of our code?&lt;/strong&gt; Just as swapping a JDBC driver leaves the application logic untouched, I implemented Debezium so it&amp;rsquo;s only responsible for &amp;ldquo;where to capture from&amp;rdquo; - everything after that (transforming, sending) is application code we write however we need.&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;Does &amp;ldquo;parallel processing while preserving order,&amp;rdquo; confirmed by the benchmark, still hold when the workers are running a real transform and sending to a real Kafka, not just an id?&lt;/strong&gt; Last time I measured order with a single id; this time I reproduced that same conclusion with a small application that transforms real columns and sends to a real Kafka.&lt;/li&gt;&#xA;&lt;/ol&gt;&#xA;&lt;h2 id=&#34;the-full-data-flow&#34;&gt;The Full Data Flow&lt;/h2&gt;&#xA;&lt;p&gt;Multi-source only branches at the Debezium connector stage. Everything after that (TRD1 - worker pool - TRD2 - KafkaSink) is handled by exactly the same code regardless of source, and it all lands in the same topic.&lt;/p&gt;</description>
    </item>
    <item>
      <title>SMTs Can&#39;t Be Parallelized — Boosting Throughput Outside Debezium While Preserving Order</title>
      <link>/en/2026/08/debezium-smt-cant-parallelize/</link>
      <pubDate>Tue, 18 Aug 2026 22:57:37 +0900</pubDate><author>gywndi@gmail.com (gywndi)</author>
      <guid>/en/2026/08/debezium-smt-cant-parallelize/</guid>
      <description>&lt;h1 id=&#34;cdc-and-debezium&#34;&gt;CDC and Debezium&lt;/h1&gt;&#xA;&lt;p&gt;When you need to sync data in real time between heterogeneous systems (RDBMS, search engines, caches, other services&amp;rsquo; databases, etc.), periodically polling the source database has limits in both scalability and latency. CDC (Change Data Capture) is the standard way to solve this — reading a database&amp;rsquo;s change log in real time and turning those changes into events delivered to wherever they&amp;rsquo;re needed. Debezium is one of the most widely used open-source tools for implementing CDC, and it&amp;rsquo;s a common core component in data-sync pipelines across heterogeneous systems.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
