Which HTTP errors should never trigger an automatic retry?

Question

I\'m trying to make a few microservices more resilient and retrying certain types of HTTP requests would help with that.

Retrying timeouts will give clients a terribly s

Answer 1

4xx codes mean that an error has been made at the caller's side. That could be a bad URL, bad authentication credentials or anything that indicates it was a bad request. Therefore, without fixing that problem, there isn't an use of retry. The error is in caller's domain and caller should fix it instead of hoping that it will fix itself.

There are exceptions. Let's imagine the service is being redeployed or restarted. At that instance, there is no endpoint registered and hence will send 4xx http code. However, a moment later, the server could be available. A retry might therefore seem beneficial.

A deeper analysis will indicate that a service, when restarted, should be a rolling restart to prevent outage. Therefore, the previous argument no longer holds true. However, if your environment/ecosystem does not follow this practice and you believe client side reported error (4xx codes) are worth retry due to aforementioned reason, then you may choose to do so; but mature systems won't do that due to no benefits perceived and losing the fail fast ability.

5xx error codes should be retried as those are service errors. They could be short term (overflowing threads, dependent service refusing connections) or long term (system defect, dependent system outage, infrastructure unavailable). Sometimes, services reply back with the information (often headers) whether this is permanent or temporary; and sometimes a time parameter as to when to retry. Based on these parameters, callers can choose to retry or not.

1xx, 2xx and 3xx codes need not be retried for obvious reasons.