If your application experiences a short-lived, temporary (or transient) failure connecting to an external service, it should transparently retry the failed operation.
The most common example of this type of transient failure is connecting to a database that is overloaded and responding to new connection requests by refusing the connection(A website retrying to connect with a database multiple times)
For applications depending on this database, you should define a retry policy to retry
the connection multiple times, with a back-off strategy that waits an increasing amount of time between retries.
With these definitions, only after the desired number of attempts have been made and failed does the retry mechanism raise an exception and abort further retry attempts.
When your web application is a client of an external service, implementing smart retry logic increases the resiliency of your website because it will recover from transient failures that occur in communicating with the external service.
Implementing the Retry pattern for a website that is a service by returning error codes for transient failures that are distinct from error codes for permanent failures improves your web- site’s scalability and resiliency.
This occurs because the service logic can guide client requests expecting that the client will retry the operation that resulted in a transient failure in the near future.
There are no words to show my appreciation!