reactor-core/src/main/java/reactor/core/publisher/Mono.java
public final Mono<T> retryBackoff(long numRetries, Duration firstBackoff) {
		return retryBackoff(numRetries, firstBackoff, Duration.ofMillis(Long.MAX_VALUE), 0.5d);
	}
public final Mono<T> retryBackoff(long numRetries, Duration firstBackoff) {
		return retryBackoff(numRetries, firstBackoff, Duration.ofMillis(Long.MAX_VALUE), 0.5d);
	}
public final Mono < T > retryBackoff ( long numRetries , Duration firstBackoff ) { return retryBackoff ( numRetries , firstBackoff , Duration . ofMillis ( Long . MAX_VALUE ) , 0.5d ) ; }
In case of error, retry this {@link Mono} up to {@code numRetries} times using a
randomized exponential backoff strategy (jitter). The jitter factor is {@code 50%}
but the effective backoff delay cannot be less than {@code firstBackoff}.
<p>
The randomized exponential backoff is good at preventing two typical issues with
other simpler backoff strategies, namely:
<ul>
<li>
having an exponentially growing backoff delay with a small initial delay gives
the best tradeoff between not overwhelming the server and serving the client as
fast as possible
</li>
<li>
having a jitter, or randomized backoff delay, is beneficial in avoiding "retry-storms"
where eg. numerous clients would hit the server at the same time, causing it to
display transient failures which would cause all clients to retry at the same
backoff times, ultimately sparing no load on the server.
</li>
</ul>

<p>
<img class="marble" src="doc-files/marbles/retryBackoffForMono.svg" alt="">

@param numRetries the maximum number of attempts before an {@link IllegalStateException}
is raised (having the original retry-triggering exception as cause).
@param firstBackoff the first backoff delay to apply then grow exponentially. Also
minimum delay even taking jitter into account.
@return a {@link Mono} that retries on onError with exponentially growing randomized delays between retries.
In case of error retry this { @link Mono } up to { @code numRetries } times using a randomized exponential backoff strategy ( jitter ) . The jitter factor is { @code 50% } but the effective backoff delay cannot be less than { @code firstBackoff } . <p > The randomized exponential backoff is good at preventing two typical issues with other simpler backoff strategies namely : <ul > <li > having an exponentially growing backoff delay with a small initial delay gives the best tradeoff between not overwhelming the server and serving the client as fast as possible < / li > <li > having a jitter or randomized backoff delay is beneficial in avoiding retry - storms where eg . numerous clients would hit the server at the same time causing it to display transient failures which would cause all clients to retry at the same backoff times ultimately sparing no load on the server . < / li > < / ul >