anchor.diff:  Although our tutorial doesn't explicitly use them, you can certainly use http://docs.confluent.io/3.1.2/schema-registry/docs/index.html[Confluent's Avro Converter] with Debezium. As mentioned link:#why-are-events-so-large[above], the Avro Converter is much smarter and serializes the event messages much more compactly than the JSON converter that is used by default.
   
   If you are deploying Debezium connectors to a Kafka Connect worker service, simply make sure the Avro Converter JARs are available and configure the worker service to use the Avro Converter. You will, for example, need to point the converter to your Confluent Schema Registry. Then, simply deploy the Debezium connectors (or really, any other Kafka Connect connectors) to your worker service.
  +See link:/docs/configuration/avro[Avro Serialization] for a detailed description of how to use the Avro converter.
   
  -Our current Docker images for Kafka Connect don't include the Avro Converter as an option. We'll likely change this in the future.
  +Our Docker images for Kafka Connect include the Avro Converter as an option.
   
   == What happens when an application stops or crashes?
   
   To consume the change events for a database, an application creates a Kafka consumer that will connect to the Kafka brokers and consume all events for the topics associated with that database. The consumer is configured to periodically record its position (aka, offset) in each topic. When an application stops gracefully and closes the consumer, the consumer will record the offsets for the last event in each topic. When the application restarts at any later time, the consumer looks up those offsets and starts reading the very next events in each topic. Therefore, under normal operating scenarios, the application sees every event *exactly one time*.
   
  -If the application crashes unexpectedly, then upon restart the application's consumer will look up the _last recorded offsets_ for each topic, and start consume events from the last offset for each topic. In most cases, the application will see some of the same events it saw prior to the crash (but after it recorded the offset), followed by the events it had not yet seen. Thus, the application sees every event *at least once*. The application can reduce the number of events seen more than once by recording the offsets more frequently, although doing so will negatively affect performance and throughput of the client. 
  +If the application crashes unexpectedly, then upon restart the application's consumer will look up the _last recorded offsets_ for each topic, and start consume events from the last offset for each topic. In most cases, the application will see some of the same events it saw prior to the crash (but after it recorded the offset), followed by the events it had not yet seen. Thus, the application sees every event *at least once*. The application can reduce the number of events seen more than once by recording the offsets more frequently, although doing so will negatively affect performance and throughput of the client.
   
   Note that a Kafka consumer can be configured to connect and start reading with the most recent offset in each topic. This can result in missed events, though this is perfectly acceptable for some use cases.
   
  
positive.code: 
  == What is Change Data Capture?
  
  Change Data Capture, or CDC, is an older term for a system that monitors and captures the changes in data so that other software can respond to those changes. Data warehouses often had built-in CDC support, since data warehouses need to stay up-to-date as the data changed in the upstream OLTP databases. 
  
  Debezium is essentially a modern, distributed open source _change data capture platform_ that will eventually support monitoring a variety of database systems.
  
  
negative.code: :linkattrs:
  :icons: font
  :toc:
  :toc-title:
  :toc-placement: macro
  
  toc::[level=2]
  