anchor.diff:  
   Event sourcing mimics how a database works, but at the application-level. Per Figure 2, the figure could be updated to represent a database as shown in Figure 3 with roughly the same design.
   
  -[.text-center]
  -image::/images/2020-02-06-event-sourcing-vs-cdc/figure03.png[]
  -[.text-center]
  +[.centered-image.responsive-image]
  +====
  +++++
  +<img src="/images/2020-02-06-event-sourcing-vs-cdc/figure03.png" style="max-width:100%;" class="responsive-image">
  +++++
   *Figure 3. Representation of Database Transaction Materializing a Table*
  +====
   
   The comparison between Figure 2 and Figure 3 will become more relevant as we dive deeper into how Event Sourcing and Change Data Capture compare to each other.
   
  
positive.code: 
  After the transaction completes, the domain events are then picked up by a CDC connector and forwarded to interested consumers using a reliable message broker (see Figure 5). Those consumers may then use the domain events to materialize their own aggregates (see above per Event Sourcing).
  
  [.text-center]
  image::/images/2020-02-06-event-sourcing-vs-cdc/figure05.png[]
  [.text-center]
  *Figure 5. Outbox Pattern implemented with CDC (2 Options)*
  
  The Outbox is also meant to be abstracted from the application as it’s only an ephemeral store of outgoing event data, and not meant to be read or queried. In fact, the domain events residing in the Outbox may be deleted immediately after insertion!
  
  
negative.code: 
  As you can see, CDC is a relatively simple concept with a very narrow scope. It’s simply externalizing the transaction log of the database as a stream of events to interested consumers.
  
  [.centered-image.responsive-image]
  ====
  ++++
  <img src="/images/2020-02-06-event-sourcing-vs-cdc/figure04.png" style="max-width:100%;" class="responsive-image">
  ++++
  *Figure 4. Change Data Capture Implementation Options*
  ====
  
  CDC also gives you flexibility on how events are consumed. Per Figure 4:
  
  