Different redelivery retry strategies

[zhelezkov]

Is your feature request related to a problem? Please describe.
From what I found, currently, LavinMQ supports basic redelivery behavior, but retry logic is fairly limited and uniform. In real-world systems, different consumers and message types often require different retry strategies (e.g., immediate retries, exponential backoff, fixed delays, or custom retry schedules).

Without flexible retry strategies, it’s difficult to balance fast recovery from transient failures with protecting downstream systems from overload or retry storms. This often forces retry logic to be implemented at the application level, leading to duplicated, inconsistent, and harder-to-maintain code.

Describe the solution you'd like
I’d like LavinMQ to support configurable redelivery retry strategies at the broker level. Examples of such strategies could include:

• Fixed delay retries (e.g., retry every N seconds)
• Exponential backoff

BullMQ has a very clear and well-documented model for retrying failed jobs that demonstrates the flexibility and ergonomics this feature could have:
https://docs.bullmq.io/guide/retrying-failing-jobs

Describe alternatives you've considered
I've tried implementing retry logic entirely in consumers (timers, delayed requeueing, backoff logic). This increases complexity and duplicates logic across services.

[kickster97]

Thank you for your feedback, Its something we have been discussing for a while, so definitely interesting.
A lot of these things are possible to do already with existing functionality of delays and dead lettering, but it gives a stronger UX if we can package it in a good way like you are describing.
We are looking into it.