How does Spring Kafka's @RetryableTopic differ from blocking retries with DefaultErrorHandler?

Blocking retries (DefaultErrorHandler with a BackOff) seek the consumer back and redeliver the failed record to the same listener, waiting out the back off on the consumer thread, so that consumer does not move past the record until it succeeds or the recoverer runs. The default BackOff is FixedBackOff with no delay and 9 retries. @RetryableTopic (since Spring Kafka 2.7) is non-blocking: if processing fails, the message is forwarded to a retry topic with a back off timestamp. The retry topic consumer checks the timestamp and, if it is not due, pauses consumption of that topic's partition, resuming when it is due; after repeated failures the message goes to the next retry topic and finally to the dead letter topic. For example, an exponential back off of 1000 ms, multiplier 2 and 4 attempts creates main-topic-retry-1000, main-topic-retry-2000, main-topic-retry-4000 and main-topic-dlt. The default is 3 attempts with a fixed 1000 ms back off. The main topic keeps flowing, but you lose Kafka's ordering guarantees for that topic, and non-blocking retries are not supported with batch listeners or container transactions. The retry and DLT consumers use group ids built from the listener's groupId plus the topic suffix. Since 2.8.4 you can combine blocking and non-blocking retries.

Expected key concepts: @RetryableTopic, DefaultErrorHandler, blocking, non-blocking, back off, dead letter topic, DLT, ordering, FixedBackOff