Previous Post Recap

In the previous post, I confirmed that splitting the Debezium embedded engine’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.

This post set out to build two things.

1. Can you swap MySQL for Postgres without changing a single line of our code? Just as swapping a JDBC driver leaves the application logic untouched, I implemented Debezium so it’s only responsible for “where to capture from” - everything after that (transforming, sending) is application code we write however we need.
2. Does “parallel processing while preserving order,” confirmed by the benchmark, still hold when the workers are running a real transform and sending to a real Kafka, not just an id? 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.

The Full Data Flow

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.

CDC and Debezium

When you need to sync data in real time between heterogeneous systems (RDBMS, search engines, caches, other services’ 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’s change log in real time and turning those changes into events delivered to wherever they’re needed. Debezium is one of the most widely used open-source tools for implementing CDC, and it’s a common core component in data-sync pipelines across heterogeneous systems.

There comes a point where a single MySQL instance just can’t keep up with the data anymore. Vitess is one of the approaches YouTube, Slack, and GitHub have used to solve this problem. I worked through what Vitess actually does, what components it’s made of, and how those components should actually be laid out, by building it myself in a local Docker environment. The setup shown here is posted as-is in a GitHub repo, and you can spin it up yourself with nothing but Docker.

Comments Were Piling Up

When someone leaves a comment on my café’s guestbook, a human doesn’t review it first — a local LLM does. It decides whether the comment is abusive, an ad, or just a nice review, and handles it automatically.

https://cafepurplemint.com (a tiny bit of shameless promotion)

Then one day, while going through the logs, I noticed something odd.

[MOD] Processing 5 pending entries...
[MOD] Processing 5 pending entries...
[MOD] Processing 5 pending entries...

The same log line kept repeating. The next poll was kicking off before the previous batch had finished processing.

Fixing a Homepage After 3 Years

My wife currently runs an unmanned cafe. And three years ago, I built the cafe’s homepage on WordPress.

Since then, I’d barely touched it. Menus changed, images changed, but the homepage just sat there. Maintaining it was too much of a hassle. One day I opened it up and it was completely out of sync with reality — discontinued items were still listed, and current items were missing.

The problem you run into with Claude Code

These days, more and more developers are using Claude Code.

Claude Code is Anthropic’s AI coding tool — you describe what you want in the terminal, and it writes the actual code for you. It’s genuinely powerful.

But if you’ve used it for a while, you’ve probably run into something like this.

“Build me a sign-up feature.”

That’s all you said, and Claude starts churning out everything from database design to API code. At first it feels like “wow, that’s fast!” — but look closer, and it’s often not what you actually wanted.