Why Just Publishing Events Isn’t Enough

Domain Events vs Change Data Capture: The Hard Truth About Using the Right Pattern for the Right Job

This week is different; I'm excited to welcome a guest writer:

Marcos F. Lobo 🗻

, a Senior Software Engineer and Tech Lead with over 20 years of experience.

He's building a SaaS product on a microservices-based cloud architecture. Before that, he worked at CERN in the IT CLOUD group, managing services on OpenStack.

In this piece, he breaks down two often-confused integration patterns: Domain Events and Change Data Capture (CDC).

It's a must-read for anyone working with event-driven systems or thinking about integrating services at scale.

Marcos, over to you.

---

I've been saying this a lot this year:

A Great Software Engineer sharpens their people skills—but never let their technical edge dull.

This is why I'm writing something more technical for you today. Also, event-driven architectures are gaining momentum in many companies nowadays… maybe yours will soon!

Most teams adopt event-driven systems without understanding the patterns. That's normal; Nobody is born knowing.

One common mistake is selecting the wrong patterns to use.

In today's issue, I will explain:

• Domain Events Pattern

• Change Data Capture Pattern

• When to use Domain Events or CDC

Before that, let me explain a bit about the problem I found from my experience.

Many teams that never implemented event-driven architectures think that the work to do is just publishing their data in a message broker system. In reality, it's more complex than that.

Depending on the use case, you must choose the right pattern to implement.

👉🏼 Domain Events and Change Data Capture are different things and, hence, used for different purposes.

It's fair to say that defining a system as event-driven from scratch makes things easier.

On the other hand, when an existing system needs to evolve to an event-driven architecture, things become more complex, so choosing the right patterns makes the difference.

Now we have a bit more context.

1. I will explain what Domain Events and Change Data Capture are later.

2. I will explain how to identify when you need one pattern over another.

Let's get started.

The Domain Event Pattern

Every application has a domain: concrete information and business logic.

👉🏼 Domain events represent significant events that have occurred in the business within the context of a domain.

The main characteristics of a domain event are:

• They express business intent and meaning, not just database changes.

• They are explicit and designed by developers.

• They are published within the application code when something relevant occurs.

• They can trigger actions in other services.

Trying to explain it in plain:

A domain event is a message your application emits for the rest of the domains to be aware of in case they care.

Let me give you an example of the information that could hold a domain event. Imagine an HR component. When a user is placed in the system, you could emit a domain event like:

Please note three important points:

• This domain event does not directly reflect database changes but describes a relevant business event. In this example, the user component indicates that a user has been assigned to a department.

• Domain Events are not emitted because of DB changes; they are emitted before or during them, reflecting domain decisions.

• It can trigger processes such as invoicing, notifications, or inventory updates. In this example, another component, like the one for payrolls or onboarding, could read this, update the inventory in the system, emit its own domain event for the rest of the world to know, and keep the wheel rolling.

  

  Domain Events flow

Now, let's continue with the next pattern.

The Change Data Capture Pattern

*** From now on, I will refer to Change Data Capture as CDC.

CDC is a technical pattern for detecting and capturing changes in a database and sending them to other systems.

The main characteristics of a CDC are:

• Based on database changes (not business logic).

• Implemented using transaction logs (like Debezium with MySQL/PostgreSQL).

• Typically emits INSERT, UPDATE, or DELETE events.

• Its purpose is to replicate data or keep systems synchronized.

Let me give you an example.

Imagine you have a service that stores data, like users, in a database. The SQL instruction looks like this:

Once that transaction is in place, the CDC is shipped, and it could look like this:

As you can see, we are defining a change. In this example, the operation is `create` and indicates the result after the transaction.

This is how it looks in a real-life example:

The user updates the email.

And the CDC would look like this:

You can appreciate that this CDC gives you the change set and nothing about what happened in the business.

The CDC's data structure is just a simple proposal indicating the operation, the state before, and the state after. Adapt it for your use case.

Again, notice three important points:

• These events are a technical reflection of the database change with no explicit business context.

• It is helpful for data replication, auditing, or system integration. But, it introduces tight coupling to the internal DB schema. If the schema changes, consumers may break.

• CDC should be avoided as a public integration layer. Use it for internal sync or read model updates, not cross-service communication in microservices.

  

  Change Data Capture flow

When to use Domain Events or CDC

I can differentiate between both patterns through 5 criteria.

5 Criteria Differentiating Domain Events and Change Data Capture Patterns

One important example that can help you better understand the difference between the two patterns. Let's go back to the CDC case and update the record.

If you need to make a change, like activating a user.

You should use a domain event like this.

Because you are modeling a business intention: activate a user.

How is it going so far?

If something is not clear to you, leave a comment on Substack. I answer all of them!

Let's wrap up for today.

Takeaways

Keep this in mind:

• Domain Events model a business intention.

• CDC indicates a change in the data, not a business intention.

• CDCs and Domain Events serve distinct purposes and are not interchangeable.

• Domain Events and CDC are not mutually exclusive; you can use both, but ensure you use each for the right use case.

• Use Domain Events as much as you can if you are in an event-driven architecture.

---

Thanks again to

Marcos F. Lobo 🗻

for the clear and thoughtful breakdown.

Let us know if this sparked new ideas or helped clarify a fuzzy concept. I'll make sure your feedback reaches him.

You can also find him writing at The Optimist Engineer; follow him!

---

Want to master real-world software engineering techniques? CodeCrafters offers hands-on challenges that help you build production-ready systems from the ground up.

• Write your own Redis, Git, or Docker to understand how the best tools work under the hood.

• Develop resilience and scalability by building real-world software components.

• Level up your system design skills with practical exercises inspired by industry challenges.

Sign up and get 40% off if you upgrade.

Thank you to our sponsors who keep this newsletter free!

---

System Design Classroom is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

---

Articles I enjoyed this week

• How Figma Scaled to 4M Users—Without Fancy Databases by

  Neo Kim

• What is Change Data Capture (CDC)? by

  Ashish Pratap Singh

• Pessimistic vs Optimistic Locking by

  Saurabh Dashora

• How (not to) fail a system design interview by

  Franco Fernando

• Enforcing the use of AI in engineering teams - good or bad thing? by

  Gregor Ojstersek

• How To Refactor Legacy Code by

  Daniel Moka

---

Thank you for reading System Design Classroom. If you like this post, share it with your friends!