Retries can be useful in case of

Temporary network problems such as packet loss

Internal errors of the target service, e.g. caused by an outage of a database

No or slow responses due to a large number of requests towards the target service

Keep in mind, however, that if the problems are caused by the target service being overloaded, retrying might make those problems even worse. To avoid turning your resilience pattern into a denial of service attack, retry can be combined with other techniques such as exponential backoff or a circuit breaker (see below).

Fallback

The fallback pattern enables your service to continue the execution in case of a failed request to another service. Instead of aborting the computation because of a missing response, we fill in a fallback value.

The following animation again depicts the payment service issuing a request to the fraud check service. Again, the fraud check service returns an internal server error. This time, however, we have a fallback in place which assumes that the transaction is not fraudulent. 

https://blog.codecentric.de/resilience-design-patterns-retry-fallback-timeout-circuit-breaker