2

Imagine a client-server architecture. The client calls some method on the server and that method fails. We want to retry. Which option is better design:

  1. The server tries calling this method again before returning a response
  2. The server returns the response immediately and the client decides if and how it wants to retry
  • These options are nearly identical in asynchronous communication. – Basilevs May 22 '18 at 8:40
  • 4
    There isn't a single best answer here. Different applications have different requirements. Some applications may prefer low-latency responses, even if the response is an error. Others might want to minimize the number of requests. If the failure was caused by a part of your backend, then your server may be in a better position to judge whether that failure is recoverable (e.g. let a load balancer retry requests on a different process if one server process crashed). – amon May 22 '18 at 8:46
  • 3
    Why did it fail? First of all, you will need retry logic on the client anyway, because some failures are in the network. Beyond that, sometimes the best course of action is not to retry, and sometimes deciding the best course of action requires information that the client has, or should be left to the user to decide. On the other hand, is there something the server can do to decrease the likelyhood of the failure? - ah, and to not forget to properly log. – Theraot May 22 '18 at 9:56
  • I agree with @Theraot completely, there can be any number of reasons why your request is getting failed. At the client-side, you can check for a few of the HTTP error codes and can retry the request. On top of that, I would prefer to have retry logic at the server-side as well but it is very unlikely I would go for this option as it can increase response latency and again there can be number of reasons it was failing. – sidgujrathi Feb 17 at 9:40
1

If the server decides when, how or how often to retry, then you can change your retry strategy at any time without having to modify the client. You may even use different strategies on different weekdays or at different times of the day; whatever suits your needs.

On the other hand, a server can only retry promptly as the client needs to uphold a connection or some sort of session with the server until it gets a reply. If it is the client that retries, it can retry in 15 minutes, two days, or even three months as only the client has to hold state for that.

However, how would the client know when it is a good point in time to retry? The answer is: It cannot. So a compromise between the two schemes would be: The client retries but the server tells it when, how and whether to retry at all. That way the server doesn't need to keep any state and the client doesn't have to keep a connection open, yet the server is still in control and you can still change your strategy at any time without modifying the client first.

After all, the question is: How useful is it to retry the same request immediately? Isn't it likely to fail again? In many cases it is, in some cases it isn't. For the third scheme it won't matter, though, as it is flexible enough to handle both cases very well. The only reason for choosing the first scheme is that it will save bandwidth (every new request from the client requires bandwidth, just like telling the client that its last request did fail) and processing time (a new request started from scratch certainly costs more processing time than just repeating an operation in a running one). So as often, the answer is: It depends.

New contributor
Mecki is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
0

A lot is going to depend what you are really trying to achieve. If you have the retries server side then this will mean if you build another client, which makes the same call to the server, it will have retry functionality built in 'for free', which could be nice.

However, you may have a requirement to customise and/or feedback on the retry attempts. If you want to do that then you may find it easier to handle the retry logic client side. You could of course have message pass back and forth between the client and server, with the server requiring a 'retry configuration' to be sent from the client (e.g. do not retry, retry three time etc).

I've built retry mechanisms before on the server side where the client was pretty much dumb so it made sense to have it there, similarly I've had retry functionality on the client side where i have wanted the client to be able to decide whether to retry again. In short I don't think there's a definitive right or wrong here without more information about your system.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.