anchor.diff:  
   == Registry
   
  -Then there is the third approach that combines strong points of the first two while it removes their drawbacsk at the cost of introducing a new component - registry - that stores and versions message schemas.
  -
  -Debezium's preferred choice is https://github.com/Apicurio/apicurio-registry[Apicurio Registry]. The project provides not only the registry itself but also client libraries and tight integration with Apache Kafka and Kafka Connect in form of serializers and converters.
  -
  -Apicurio enables Debezium and consumers to exchange messages whose schema is stored into the registry and pass only reference to the schema in the message.
  -Also as the source table and thus message schema evolves, the registry versions the schemas so not only current but also historical schemas are available.
  +Then there is the third approach that combines strong points of the first two, while it removes their drawbacks at the cost of introducing a new component - a registry - that stores and versions message schemas.
  +
  +There are multiple schema registry implementations available;
  +in the following we're going to focus on the https://github.com/Apicurio/apicurio-registry[Apicurio Registry],
  +which is an open-source (Apache license 2.0) API and schema registry.
  +The project provides not only the registry itself, but also client libraries and tight integration with Apache Kafka and Kafka Connect in form of serializers and converters.
  +
  +Apicurio enables Debezium and consumers to exchange messages whose schema is stored in the registry and pass only a reference to the schema in the messages themselves.
  +A the structure of captured source tables and thus message schemas evolve, the registry creates new versions of the schemas, too, so not only current but also historical schemas are available.
   
   Apicurio provides multiple serialization formats out-of-the-box:
   
  -* https://avro.apache.org/[Avro]
   * JSON with externalized schema support
  +* https://avro.apache.org/[Apache Avro]
   * https://developers.google.com/protocol-buffers[Protocol Buffers]
   
  -Every serializer and deserializer knows how to automatically interact with Apicurio API so the consumer is isolated from it as an implementation detail.
  +Every serializer and deserializer knows how to automatically interact with the Apicurio API so the consumer is isolated from it as an implementation detail.
   The only information necessary is the location of the registry.
   
  -Apicurio also provides API compatibility layers for Confluent Schema Registry and IBM Schema Registry.
  -This is a very useful feature as it enables the use of 3rd party tools like https://github.com/edenhill/kafkacat[kafkacat] even if they are not yet aware of the native API.
  +Apicurio also provides API compatibility layers with the Confluent Schema Registry and IBM Schema Registry.
  +This is a very useful feature as it enables the use of 3rd party tools like https://github.com/edenhill/kafkacat[kafkacat], even if they are not yet aware of the native API.
   
   === JSON Converter
   
  
positive.code: }
  ----
  
  which is the same as we have seen in the `JSON` with schema example.
  
  The connector registration request differs in a few lines from the standard one:
  
  [source,json]
  ----
          (1) "key.converter": "io.apicurio.registry.utils.converter.ExtJsonConverter",
          (2) "key.converter.apicurio.registry.url": "http://apicurio:8080",
          (3) "key.converter.apicurio.registry.global-id": "io.apicurio.registry.utils.serde.strategy.AutoRegisterIdStrategy",
          (1) "value.converter": "io.apicurio.registry.utils.converter.ExtJsonConverter",
          (2) "value.converter.apicurio.registry.url": "http://apicurio:8080",
          (3) "value.converter.apicurio.registry.global-id": "io.apicurio.registry.utils.serde.strategy.AutoRegisterIdStrategy"
  ----
  
  . Apicurio JSON converter is used as both key and value converter
  . Option points to the actual Apicurio registry endpoint
  . This setting ensures that it is posible to automatically register the schema id which is typical setting in Debezium deployment
  
  === Avro Converter
  
  So far we have demonstrated serialization of message into the `JSON` format only.
  While `JSON` format has a lot of advantages like easy human readibility it still contains a lot of content unrelated to the data itself.
  
  To transfer really only the data without any significant overhead it is useful to use binary format serialization like Avro format.
  In this case, we would pack the data only without any field names and other ceremony and again the message will contain a reference to a schema stored in the registry.
  
  Let's look at how easily the Avro serialization can be used with Apicurio's Avro converter.
  
  
negative.code: }
  ----
  
  Note how no type information beyond JSON's basic type system is present.
  E.g. a consumer cannot conclude from the event itself, which length the numeric `id` field has.
  
  The example of the second case is again `JsonConverter`.
  By means of its `schemas.enable` option, the JSON message will consist of two parts - `schema` and `payload`.
  The `payload` is exactly the same as in the previous case but the `schema` contains a description of the message, its fields, field types and associated type constraints.
  This enables the consumer to process the message in a type-safe way.
  The drawback of this approach is that the size of the message has increased significantly, as the schema is quite a large object.
  As schemas tend to be changed rarely (how often do you change the definitions of the columns of your database tables?),
  adding the schema to each and every event poses a signficant overhead.
  
  The example of a message with a schema clearly shows that the schema itself can be significantly larger than the payload and is not very economical to use:
  
  [source,json]
  ----
  