anchor.diff:  
   == What happens when an application stops or crashes?
   
  -To consume the change events for a database, an application creates a Kafka consumer that will connects 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*.
  +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. 
   
  -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 acceptible for some use cases.
  +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.
   
   == What happens when Debezium stops or crashes?
   
  
positive.code: 
  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. 
  
  Debeziumm is essentially a modern, distributed open source _change data capture platform_ that will eventually support monitoring a variety of database systems.
  
  == What databases can Debezium monitor?
  
  
negative.code: 
  Meanwhile, the Kafka Connect services serialize the connector's events and record them in Kafka. The JSON converter is very generic and very simple, but it has no choice but to serialize the entire event information. Therefore, events represented in JSON are indeed verbose and large.
  
  However, http://docs.confluent.io/3.1.2/schema-registry/docs/index.html[Confluent's Avro Converter] is much smarter in two ways. First, it converts the connector's schema into an https://avro.apache.org[Apache Avro schema], so the payload can be serialized into a https://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.html[very compact binary form]. Secondly, it uses the fact that many events in a row will use the same schema (and thus Avro schema), and by registering those Avro schemas in a separate http://docs.confluent.io/3.0.0/schema-registry/docs/index.html[Schema Registry], it can place into each serialized event a small _identifier_ of the schema version used by the message. The Avro Converter and the Schema Registry can work together to track the history of each schema over time.
  
  Meanwhile, in the consumer, the same Avro Converter decodes the compact binary form of the event, reads the identifier of the schema version used by that message, if it hasn't yet seen that schema version downloads the Avro schema from the Schema Registry, and finally uses that Avro schema to decode the binary payload of the event. Again, many events in sequence will share the same schema (and Avro schema version), so most of the time the converter can simply decode the raw compact event into the same schema and payload expected by the consumer.
  
  