anchor.diff:  
   When all systems are running nominally or when some or all of the systems are gracefully shut down, then consuming applications can expect to see every event *exactly one time*. However, when things go wrong it is always possible for consuming applications to see events *at least once*.
   
  -When the Debeium's systems crash, they are not always able to record their last position/offset. When the are restarted, they recover by starting where were last known to have been, and thus the consuming application will always see every event but may likely see at least some messages duplicated during recovery.
  +When the Debezium's systems crash, they are not always able to record their last position/offset. When they are restarted, they recover by starting where were last known to have been, and thus the consuming application will always see every event but may likely see at least some messages duplicated during recovery.
   
  -Additionally, network failures may cause the Debezium connectors to not receive confirmation of writes, resulting in the same even being recorded one or more times (until confirmation is received).
  +Additionally, network failures may cause the Debezium connectors to not receive confirmation of writes, resulting in the same event being recorded one or more times (until confirmation is received).
   
   == What is Kafka?
   
  
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: 
  == 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. 
  
  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?
  
  