anchor.diff:  Both Rabbit and Kafka support these concepts. However, other binders may not, so refer to your individual binder’s documentation for details on supported system-level
   error-handling options.
   
  -====== Drop Failed Messages
  +===== Drop Failed Messages
   
   By default, if no additional system-level configuration is provided, the messaging system drops the failed message.
   While acceptable in some cases, for most cases, it is not, and we need some recovery mechanism to avoid message loss.
   
  -====== DLQ - Dead Letter Queue
  +===== DLQ - Dead Letter Queue
   
   DLQ allows failed messages to be sent to a special destination: - _Dead Letter Queue_.
   
  
positive.code: 
  This may be a convenient option if error handling logic is the same regardless of which handler produced the error.
  
  ===== System Error Handling
  
  System-level error handling implies that the errors are communicated back to the messaging system and, given that not every messaging system
  is the same, the capabilities may differ from binder to binder.
  
negative.code: Once set, the failed message is resubmitted to the same handler and loops continuously or until the handler throws `AmqpRejectAndDontRequeueException`
  essentially allowing you to build your own re-try logic within the handler itself.
  
  ==== Retry Template
  
  The `RetryTemplate` is part of the https://github.com/spring-projects/spring-retry[Spring Retry] library.
  While it is out of scope of this document to cover all of the capabilities of the `RetryTemplate`, we will mention the following consumer properties that are specifically related to
  