Retry Pattern Vs rest client return template

Question

We have several resources that are open as a REST service and are working on the development of the argument whether the client needs to implement repeated logic if the service is unavailable due to network and / or application layer failures. Is it worth it? One group claims that if the service is unavailable, then it makes no sense to try again, but the other group claims that there may be problems with online employment and a retry can help. There are currently no statistics to protect arguments. How about implementing a return URL (replica of the original http resource) and using the return service during failures.

Any suggestions based on your previous experience?

Answer 1

Keep in mind that if a service request fails, it may be due to network congestion. In this case, an immediate failure is the best option. Regarding the use of the return URL, it probably won’t solve your problem, as it can support the network under high load.

The suggestion is to take a look at patterns such as:

• Backpressure : http://mechanical-sympathy.blogspot.com.br/2012/05/apply-back-pressure-when-overloaded.html , http://engineering.voxer.com/2013/09/16/backpressure- in-nodejs /
• Circuit Breaker , Load Drop : http://martinfowler.com/bliki/CircuitBreaker.html , http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html
• Bulkhead Template : http://skife.org/architecture/fault-tolerance/2009/12/31/bulkheads.html

Answer 2

In general, it is recommended that you retry failed requests. Always set a repeat limit. Also, there are often certain server responses that signal that the client will not try again to use when the server is experiencing problems that will not be resolved by retrying later, for example, a database failure. A very good way to avoid hacking a server under high load with retry requests is to use exponential delay, for example, the first attempt after 30 seconds, the next after 300 seconds, etc.

The return URL seems unRESTful - there should be a single endpoint for the resource. The client does not care if this endpoint is supported by your main stack or backup. Typically, the dispatcher is used to distribute requests between application servers, so if it does not work, it can redirect traffic to others until the problem is fixed.