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 slow experience, so I don't intend to retry in this case. Retrying 400s doesn't help because a bad request will remain a bad request a few milliseconds later.
I imagine there are other reasons to not retry a few other types of errors, but which errors and why?
There are some errors that should not be retried because they seem permanent:
- 400 Bad Request
- 401 Unauthorized
- 402 Payment Required
- 403 Forbidden
- 405 Method Not Allowed
- 406 Not Acceptable
- 407 Proxy Authentication Required
- 409 Conflict - it depends
- 410 Gone
- 411 Length Required
- 412 Precondition Failed
- 413 Payload Too Large
- 414 URI Too Long
- 415 Unsupported Media Type
- 416 Range Not Satisfiable
- 417 Expectation Failed
- 418 I'm a teapot - not sure about this one
- 421 Misdirected Request
- 422 Unprocessable Entity
- 423 Locked - it depends on how long a resource is locked in average (?)
- 424 Failed Dependency
- 426 Upgrade Required - can the client be upgraded automatically?
- 428 Precondition Required - I don't thing that the precondition can be
fulfiled the second time without retring from the beginning of the
whole process but it depends
- 429 Too Many Requests - it depends but it should not be retried to fast
- 431 Request Header Fields TooLarge
- 451 Unavailable For Legal Reasons
So, most of the 4** Client errors should not be retried.
The 5** Servers errors that should not be retried:
- 500 Internal Server Error - it depends on the cause of the error
- 501 Not Implemented
- 502 Bad Gateway - I saw used for temporary errors so it depends
- 505 HTTP Version Not Supported
- 506 Variant Also Negotiates
- 507 Insufficient Storage
- 508 Loop Detected
- 510 Not Extended
- 511 Network Authentication Required
However, in order to make the microservices more resilient you should use the Circuit breaker pattern and fail fast when the upstream is down.