Adding resilience to your services by implementing a retry pattern

When I was developing data-driven apps for the Android platform a few years ago, there would sometimes be intermittent connection issues which would cause the app to fail. Rather than fail the entire request and log the exception, I introduced a retry pattern. Each database method would be wrapped in a try / catch block. In the catch block would be a call to the same method. To prevent the code going into an infinite loop and throwing a stackoverflow exception, I implemented the retry pattern to try a configurable number of times before giving up and throwing an exception. By implementing a retry pattern in all database methods, the prevalence of exceptions in that part of the code all but disappeared.

I have implemented the same retry pattern with my ASP.NET Web API services. Rather than throw an exception in the event of a temporal communication problem, the retry pattern enables the method to be retried from the catch block up to a configurable number of retries. I have implemented this pattern for all database methods and controllers that fetch data from third-party services.

A retry pattern adds a layer of resilience to applications that are data-driven and / or consume third-party services, or indeed where there is any level of external communication between the various moving parts of an application.