Change Data Capture and Async Triggers

Even if it says Async, it has the same set of limits as Synchronous transaction, No Extra Heap , 60 sec CPU Time or 200 SOQL. Also, the thing to remember here is it's an Event and EventTrigger and so can run with the maximum Batch size of 2000, thus if moto was to split the process into lighter one, it seems hard again.

As its a trigger, YOU CAN'T DO CALLOUT. Whereas you can do callouts in Batch/Future/Queuable.

You don't have control, let's say in AccountChangeEvent you update the account's field, it will again fire a new AccountChangeEvent CDC Event. Infinite Loops you are welcome :)

In my Opinion :

CDC is supposed to be a Data Replication API for external Systems(Or react to field change), but now SF is trying to put people use it on the platform.

If you want to build decoupled architecture, use Platform Events instead, you can control when to fire events and when to not :)

Writing a normal object trigger and its changeEventTrigger doesn't seems right in my view.

The first thing to understand is Change Event Triggers have some prerequisites in org like enabling the Change Data Capture for the object and not all objects are supported yet.

Change Event Triggers are async and break transaction hence can be useful to break transaction , which in turn can help you save the CPU time.

The future or queueable methods were for same reasons while queueable had more flexibility because of couple more reasons

1.You can enqueue a queueable job inside a queueable job (no more “Future method cannot be called from a future or batch method” exceptions).

2.You can have complex Objects (such as SObjects or Apex Objects) in the job context (@future only supports primitive data types)

When it comes to picking async triggers and queueable, if you need a proper decoupling then go for async triggers with change data capture as it looks clean in terms of architecture.

NOTE - Third party callouts will still be stopped in async triggers as callouts are not allowed so queueable seems better here .

It's based on publish and subscribe model where the processes will be loosely coupled.