Reintentos no bloqueantes con Retry Topics

Blocking retries (Spring Retry) pause the consumer thread between attempts. A long backoff blocks the partition, stalling all later records.

Non-blocking retries solve this by moving failed records to dedicated retry topics.

When processing fails, the record is forwarded to a retry topic with a delay. A separate listener consumes the retry topic after the delay and tries again.

• The main consumer keeps moving forward.
• Each retry level can have a longer delay.

Annotate your listener with @RetryableTopic. Spring auto-creates the retry and DLT topics.

Customize the number of attempts and the delay strategy directly in the annotation.

By default Spring creates topics like orders-retry-0, orders-retry-1, and finally orders-dlt.

Each retry topic corresponds to one backoff level.

Set multiplier for exponential growth, or omit it for fixed delays.

• Fixed: 1s, 1s, 1s.
• Exponential: 1s, 2s, 4s.

Exponential is better for transient downstream outages.

Only retry exceptions that are transient. Use include or exclude to control which exceptions trigger retries.

After all attempts fail, the record lands on the DLT. Add a @DltHandler method to react.

Retry records carry headers such as the attempt count and original timestamp, letting you log how far a message progressed.

Use blocking retries for very short, immediate transients; use non-blocking retry topics when delays are longer and partition throughput matters.

Non-blocking retries keep consumers responsive while still giving failed messages multiple chances. Combine @RetryableTopic, exponential backoff, exception filtering, and a @DltHandler.

You learned non-blocking retries.

• @RetryableTopic creates retry topics automatically.
• Configure attempts, backoff, and a multiplier.
• Filter retryable exceptions with include/exclude.
• Use @DltHandler for permanently failed records.