anchor.diff:  As stated above, by default Debezium will emit events for each table on distinct topics.
   Using Kafka Streams, the change event topics for both tables will be loaded into two ``KTable``s, which are joined on the customer id.
   The Kafka Streams application is going to process data from the two Kafka topics.
  -Whenever there's a new CDC event on either topic -- triggered by the insertion, update, or deletion of a record -- the join will be re-triggered.
  +Whenever there's a new CDC event on either topic -- triggered by the insertion, update, or deletion of a record -- the join will be re-executed.
   
   As a runtime for the Kafka Streams application, we're going to use https://quarkus.io/[Quarkus], a stack for building cloud-native microservices, which (amongst many others) also provides an https://quarkus.io/guides/kafka-streams[extension] for Kafka Streams. While it's general possible to run a Kafka Streams topology via a plain `main()` method, using Quarkus and this extension as a foundation has a number of advantages:
   
  
positive.code: 
  Kafka Streams applications can easily be scaled out i.e. the load is going to be shared amongst multiple instances of the application,
  each processing  a sub-set of the partitions of the input topics.
  When the Quarkus application gets compiled into native code via GraalVM it takes considerably less memory and has a very fast start-up time.
  Without any concern about the memory management, you can start multiple instances of a Kafka Streams pipeline in parallel.
  
  If you want to run this application in `native` mode, set the `QUARKUS_MODE` as `native` and run the following
  
negative.code:     -t customers-with-addresses | jq .
  ----
  
  You should see records like the following, each containing all the data of one customer and all their addresses:
  
  [source,json]
  ----
  