anchor.diff:  
   A `null` structure value represents that a column was not modified (`v2` field). If the column was assigned a `NULL` value (`v3` field), there will be a structure with a `NULL` `value` field. A non-null column assignment (`v1` field) fills the contents of the `value` field. Such a format allows us to correctly represent all the possibilities and differentiate between assigning `NULL` and non-modification. 
   
  -However, most sink connectors won’t be able to correctly parse such a structure. Therefore, we decided to develop our own SMT, based on Debezium’s https://debezium.io/documentation/reference/1.6/transformations/event-flattening.html[New Record State Extraction SMT]. Our https://github.com/scylladb/scylla-cdc-source-connector#scyllaextractnewstate-transformer[ScyllaExtractNewState] SMT works by applying Debezium's New Record State Extraction and flattening the `{"value": ...}` structures:
  +However, most sink connectors won’t be able to correctly parse such a structure. Therefore, we decided to develop our own SMT, based on Debezium’s https://debezium.io/documentation/reference/1.6/transformations/event-flattening.html[New Record State Extraction SMT]. Our https://github.com/scylladb/scylla-cdc-source-connector#scyllaextractnewstate-transformer[ScyllaExtractNewState] SMT works by applying Debezium's New Record State Extraction and flattening the `{"value": ...}` structures (at the expense of not being able to distinguish `NULL` value and missing column value):
   
   [source,json]
   ----
  
positive.code: 
  == Horizontal scaling
  
  Even at a stage of proof-of-concept, great performance was a paramount requirement. Scylla databases can scale to hundreds of nodes and PBs of data, so it became clear that a single Kafka Connect node (even multithreaded) could not handle the load of a big Scylla cluster. 
  
  Thankfully, we took that into consideration while implementing CDC functionality in Scylla. Generally, you can think of Change Data Capture as a time-ordered queue of changes. To allow for horizontal scaling, Scylla maintains a set of multiple time-ordered queues of changes, called streams. When there is only a single consumer of the CDC log, it has to query all streams to properly read all changes. A benefit of this design is that you can introduce additional consumers, assigning a disjunct set of streams to each one of them. As a result, you can greatly increase the parallelism of processing the CDC log.
  
  
negative.code: Alice |        2 | blueberries
  ----
  
  Looking only at this table, you cannot reconstruct all modifications that took place, e.g. Tim’s order name before the UPDATE. Let’s look at the CDC log, easily accessible as a table (some columns truncated for clarity):
  
  [source,sql]
  ----
  SELECT * FROM ks.orders_scylla_cdc_log;
  
   cdc$stream_id | cdc$time |     | cdc$operation | order_id | order_name  |     user
  ---------------+----------+-...-+---------------+----------+-------------+----------
      0x2e46a... |  7604... | ... |             2 |        1 |       apple |      Tim
      0x2e46a... |  8fdc... | ... |             1 |        1 |   pineapple |      Tim
      0x41400... |  808e... | ... |             2 |        2 | blueberries |    Alice
  ----
  
  All three operations are visible in the CDC log. There are two INSERTs (`cdc$operation = 2`) and one UPDATE (`cdc$operation = 1`). For each operation, its timestamp is also preserved in `cdc$time` column. The timestamp is encoded as a time-based UUID value as specified by the https://datatracker.ietf.org/doc/html/rfc4122[RFC 4122] specification, which can be decoded using helper methods in Scylla drivers.
  
  == Choosing Debezium
  
  