DEV Community: Mohammad

Listening to the Heartbeat of Your Database: Understanding Change Data Capture (CDC)

Mohammad — Fri, 19 Jun 2026 12:06:56 +0000

CDC stands for Change Data Capture.

What You Will Learn

What CDC is
The story behind it
How it works internally
Common use cases
A simplified implementation example

What Is CDC?

Change Data Capture (CDC) is a technique for capturing changes made to data and exposing those changes to external systems.

Instead of repeatedly querying a database to check whether something has changed, CDC allows applications to consume a stream of inserts, updates, and deletes as they happen.

Think of CDC as a way to listen to the heartbeat of your database.

Every time data changes, the database records that change internally. CDC makes those changes available so that other systems can react to them in real time.

The Story Behind CDC

To understand CDC, it helps to understand how databases have worked for decades.

Whenever data changes, databases do not simply overwrite the old value and move on. They maintain an internal record of operations that have occurred.

These records are commonly stored in transaction logs.

Historically, every database implemented these logs differently, but the purpose was always the same:

Record every change made to the database
Recover from failures
Replicate data to other nodes
Maintain consistency

Every insert, update, and delete operation generates a log entry.

These entries are ordered and identified by a unique position or token.

The ordering is critical.

Imagine the following sequence:

Create User
Update User
Delete User

If a replica applied these operations in a different order, it would end up with completely different data.

Because these logs are ordered, databases can reliably replay changes and reconstruct state over time.

This is how replication works in many database systems.

A replica typically starts with an initial snapshot and then continuously applies new changes by replaying the transaction log.

Where CDC Comes In

Originally, these logs were intended for the database itself.

CDC extends that idea by allowing external applications to consume those same changes.

Instead of only replicas reading database changes, your applications can read them too.

This means that whenever data changes, you can react immediately without constantly querying the database.

The underlying idea is simple:

Expose an ordered stream of database changes that external systems can consume reliably.

How CDC Works

Different databases implement CDC differently, but the concept remains the same.

MongoDB

MongoDB provides CDC through Change Streams.

Each event contains a resume token, which allows consumers to continue reading from the last processed change after a restart or failure.

MySQL

MySQL exposes changes through its Binary Log (Binlog).

CDC tools can read the binlog and transform database operations into events.

PostgreSQL

PostgreSQL provides CDC through Logical Decoding and Logical Replication.

These mechanisms allow applications to consume database changes in order.

Although the implementations differ, they all provide the same capability:

An ordered stream of database changes.

CDC Is Usually Pull-Based

One common misconception is that databases push changes directly to your application.

In reality, most CDC implementations are fundamentally pull-based.

The consumer requests the next available change from the database.

However, applications typically maintain a long-lived connection or cursor, making the experience feel very similar to receiving pushed events.

For example, MongoDB's watch() API keeps a stream open and continuously delivers new events as they become available.

From the application's perspective, it feels real-time.

A Simplified CDC Example

To understand the concept, imagine that every database change is converted into a standardized event.

function captureDataChange($operation, $table, $id, $before, $after)
{
    $cdcEvent = [
        "metadata" => [
            "operation" => $operation,
            "table" => $table,
            "id" => $id
        ],
        "before" => $before,
        "after" => $after
    ];

    echo "Streaming event: " . json_encode($cdcEvent) . PHP_EOL;
}

captureDataChange(
    "UPDATE",
    "users",
    42,
    ["name" => "Alice", "role" => "Developer"],
    ["name" => "Alice", "role" => "Architect"]
);

Output:

{
  "metadata": {
    "operation": "UPDATE",
    "table": "users",
    "id": 42
  },
  "before": {
    "name": "Alice",
    "role": "Developer"
  },
  "after": {
    "name": "Alice",
    "role": "Architect"
  }
}

Real CDC systems work differently under the hood, but the idea is very similar:

Detect a database change
Convert it into an event
Publish it to interested consumers

CDC vs Traditional Polling

Without CDC, applications often use polling.

For example:

SELECT *
FROM orders
WHERE updated_at > :last_seen_timestamp;

This approach works, but it has drawbacks:

Additional load on the database
Expensive queries at scale
Possibility of missing updates
Duplicate processing logic

CDC avoids these problems by consuming changes directly from the database's change stream.

Instead of repeatedly asking:

"Has anything changed?"

the database tells you:

"This is what changed."

Why CDC Matters

CDC is more than a database feature.

It is an architectural building block.

Once database changes become events, many new possibilities emerge.

Common use cases include:

Search index synchronization (Elasticsearch/OpenSearch)
Analytics pipelines
Event-driven architectures
Cache invalidation
Audit trails
Data warehouse synchronization
Building materialized views
Synchronizing data across services

For example, when a product is updated in your database, a CDC consumer can automatically update:

Search indexes
Caches
Reporting systems
Recommendation engines

without requiring changes to the original application.

CDC in Modern Architectures

Many organizations use CDC platforms such as Debezium to provide a unified way of consuming changes across different databases.

These platforms often publish CDC events into systems such as Apache Kafka, where multiple consumers can process the same stream independently.

This makes CDC a key building block in modern event-driven systems.

Final Thoughts

At its core, CDC is a simple idea:

Every database change is already being recorded somewhere. CDC allows external systems to listen to those changes.

Whether it is MongoDB Change Streams, MySQL Binlogs, or PostgreSQL Logical Replication, the principle remains the same:

An ordered stream of database changes that can be consumed reliably.

Once you start viewing database updates as events rather than rows being modified, CDC becomes one of the most powerful tools for building scalable and loosely coupled systems.

From Notion to Everywhere: Building Calligra

Mohammad — Thu, 18 Jun 2026 18:11:58 +0000

Every developer blog needs a first post.

Mine starts with a pen, a family name, and a workflow I got tired of doing by hand.

The Publishing Problem

I write almost everything in Notion.

It is where ideas begin, drafts evolve, and articles eventually take shape. But publishing those articles was always the same repetitive process:

Copy the content from Notion.
Fix formatting issues.
Paste it into my blog.
Repeat for Dev.to.
Repeat for Hashnode.
Repeat for Medium.
Upload cover images multiple times.
Configure canonical URLs manually.

None of these steps were difficult.

They were simply repetitive.

And as developers, repetitive work usually means there is an opportunity for automation.

The Goal

I wanted a publishing workflow that looked like this:

Notion → Calligra → Personal Blog + Dev.to + Hashnode + Medium

Write once.

Publish everywhere.

Keep my own domain as the source of truth.

That simple idea became Calligra.

What Is Calligra?

Calligra is an open-source CLI tool that takes content from Notion and publishes it to multiple destinations with a single command.

make sync
make build
make publish

Behind the scenes, Calligra:

Fetches content from the Notion API
Converts the content into platform-specific formats
Uploads images and assets
Publishes to supported platforms
Sets canonical URLs back to your own website

The goal is simple:

Your personal blog owns the content. Other platforms help distribute it.

Screenshot: Publishing Workflow

Content Flow

┌──────────┐
│  Notion  │
└────┬─────┘
     │
     ▼
┌──────────┐
│ Calligra │
└────┬─────┘
     │
     ├──► Personal Blog
     ├──► Dev.to
     ├──► Hashnode
     └──► Medium

The Story Behind the Name

Before the code, there is the name.

The Craft

The word Calligra comes from the same roots as calligraphy — the art of beautiful writing.

Calligraphy is not just about words.

It is about intention, structure, and craftsmanship.

The Heritage

My family name is Ghalambaz (قلم‌باز).

A rough translation would be:

"Pen player."

Historically, it referred to someone who practiced writing as both a craft and an art.

Someone who enjoyed working with words.

When I built a tool dedicated entirely to writing and publishing, the name felt inevitable.

Calligra connects a modern publishing workflow with a much older tradition of writing.

Open Source from Day One

Although Calligra started as a personal tool, I built it to be useful for other developers as well.

If you write in Notion or anywhere else and publish technical content, you might find it useful.

The project is open source, and contributions, feedback, and ideas are always welcome.

Repository: Ghalambaz/Calligra

Why Start This Blog?

Calligra solves the publishing problem.

Now it's time to focus on the writing.

This blog will be a place for practical engineering lessons, architectural decisions, debugging stories, and lessons learned from building software in production.

Not tutorials copied from documentation.

Not generic AI-generated content.

I do use AI—but as an editor, not an author.

AI is great at fact-checking, catching mistakes, improving clarity, challenging assumptions, and helping me communicate ideas more effectively. The experiences, opinions, successes, and failures will still be my own.

The goal is simple: share real engineering stories, real production problems, and solutions that might help someone else avoid the same mistakes.

What's Next?

This post marks the beginning of the journey, not the destination.

Over time, I'll be writing about software architecture, backend engineering, distributed systems, debugging sessions, performance bottlenecks, deployment lessons, and the occasional mistake that taught me something valuable.

Some articles will be technical deep dives.

Some will be lessons learned from real projects.

Some may simply document a problem that took far longer to solve than it should have.

The goal is not to publish content for the sake of publishing.

The goal is to share experiences, capture lessons before they are forgotten, and hopefully help other engineers who run into similar challenges along the way.

Final Thoughts

Calligra started as a way to eliminate a repetitive workflow.

Now it has become the foundation of this blog.

If you are a developer who writes in Notion and owns a personal domain, I hope it saves you time as well.

Thanks for stopping by.

See you in the next post.

—

Mohammad Ghalambaz

writing at Calligra.dev