These two strategies aim to solve the same problem, but in opposite ways.

They may sound alien or complicated if you haven't used them yet —they sure felt that way to me a few years ago— but there is no mystery to them, really.

Also, of these two, there is a clear winner and one we generally want to avoid. Can you guess which is which?

Change Data Capture

Fancy name for saving changes after effectuating them.

Something like the following, for example:

UPDATE coders SET monies = 999999999 WHERE name = "taro";
INSERT INTO changes VALUES("set monies", "taro", 999999999);

One could even say this is manually duplicating the OP log — and yes, that is a red flag.

This is one way to keep a paper trail so that any present value can be traced back if and when needed.

It makes sense for banks, legal documents, etc.

There isn’t much more to it, really. The concept is straightforward. The challenge lies in the implementation, but it isn't much of a challenge anyway.

You'll find this implemented in the wild with Postgres triggers, MongoDB Change Streams, etc.

The challenge here is: how can we guarantee that both the application of the change and the log of it succeed or fail atomically, scale well, etc?

In reality, this usually is overengineering — stemming from a lack of business direction and product planning.

When such a feature is actually needed, you'll want something more reliable: Event Sourcing.

Event Sourcing

This is the opposite of Change Data Capture. Or, rather, the actual solution to the problem CDC tries to solve.

It's a matter of prioritization, really.

Instead of making changes and then tracking them, store the changes first, then build the view or projection you need.

Event Sourcing is reliable where it matters most: the facts. If a user reports an issue regarding an invoice, for example, you'll be able to follow the data, confirm what the value should be, give some money back if needed, then fix the bug.

That is, of course, assuming the facts are being recorded properly to begin with, but this is true for CDC and any other strategies too. No system is immune to bugs.

Event Sourcing has another great strength: it fits perfectly in an Event-Driven Architecture. Separating the facts from the projection into different μServices is trivial.

Obviously, this is a sufficiently common challenge in some industries for it to have well-known tools, such as Datomic.