mjhjmtu

In Platform Events, if you throw EventBus.RetryableException, the doc states:

Events are resent after a small delay. The delay increases in
subsequent retries.

So, how small is small and how large is "increases"?

So, I ran a controlled test -- your mileage may vary.

Controlled test was 100 Platform Events submitted in a single statement

EventBus.publish(myEvents);

The consuming Apex trigger coerced a DML exception that was in turn interpreted as a "transient" exception and the Apex trigger code threw EventBus.RetryableException. No other activity was occurring on the org; no other events were published.

(100 Events) Results (# secs between each retry)

Retry 1: 15s
Retry 2: 32s
Retry 3: 27s
Retry 4: 31s
Retry 5: 29s
Retry 6: 61s
Retry 7: 60s
Retry 8: 59s
Retry 9: 61s

I repeated the experiment with a single event (rather than 100)

(1 event) Results (#secs between each retry)

Retry 1: 28s
Retry 2: 30s
Retry 3: 30s
Retry 4: 29s
Retry 5: 31s
Retry 6: 60s
Retry 7: 60s
Retry 8: 60s
Retry 9: 60s

So, based on these small test sets, I would say, that as of V44, the first 5 retries are spaced ~30s apart and the next 4 retries are spaced 60s apart. (Don't go past nine retries as otherwise your trigger will be marked in error and no new events can be consumed)

The EventBus.RetryableException exception is super useful in dealing with DmlException UNABLE_TO_LOCK_ROW and Query Exception Record Not Available

Note that it is not a panacea. Consider this:

First transaction includes events 1-10 and encounters a transient exception. Trigger throws EventBus.RetryableException

When the retry occurs, there might now be events 1-30 available to the transaction. Even if the record lock issue affecting events 1-10 has cleared, if a new record lock issue affects events 11-30 and the transaction throws EventBus.RetryableException again, events 1-10 are swept up as innocent bystanders and thrown into the replay queue along with events 11-30. And so on.