Какие HTTP коды ошибок имеет смысл ретраить, а какие нет

Что проверяют

Разделяете ли вы временные и постоянные ошибки и помните ли, что неудачный повтор бывает опаснее исходного сбоя. Хороший интервьюер сразу уводит в идемпотентность: а если это POST на создание заказа и вы получили таймаут, повторять будете?

Как отвечать

• повторять: 408, 429 строго с учётом заголовка Retry-After, 500, 502, 503, 504, а также сетевые сбои без ответа: обрыв соединения, таймаут установки, ошибка резолвинга;
• не повторять: 400, 401 (кроме одной попытки после обновления токена), 403, 404, 405, 422, 501. Ни тело запроса, ни права сами не изменятся, повтор только удвоит нагрузку;
• зависит от контекста: 409 при оптимистичной блокировке повторить осмысленно, но сначала перечитать актуальное состояние, а не слать то же тело;
• идемпотентность важнее кода: GET, HEAD, PUT, DELETE повторяются спокойно. POST нет: сервер мог выполнить операцию и потерять ответ. Решение это ключ идемпотентности в заголовке, по которому сервер отдаёт результат первой попытки вместо повторного создания;
• как повторять: экспоненциальная задержка с джиттером, чтобы клиенты не пришли одной волной, потолок в три попытки, общий дедлайн на всю операцию, размыкатель цепи, который перестаёт бить по упавшему сервису.

Отдельно скажите про бюджет повторов. Если каждый слой цепочки повторяет трижды, четыре слоя дают восемьдесят один запрос на один пользовательский. Повторы разрешают на одном уровне, обычно на ближайшем к вызову.

Раз вопрос тестировщику, назовите и проверку: подменённые ответы через WireMock или прокси вроде toxiproxy, а в сценарии проверяется не только факт повтора, но и число попыток, рост пауз и отсутствие дублей в базе.

Где спотыкаются

Повторяют POST без ключа идемпотентности и получают два заказа на один клик, причём именно тогда, когда сервис под нагрузкой.

Игнорируют Retry-After при 429 и продолжают стучаться со своей паузой. Так ограничение по частоте превращается в блокировку клиента.

Ставят повторы сразу на всех уровнях: в HTTP-клиенте, в сервисном слое и в обработчике очереди. Умножение попыток добивает сервис, который только начал восстанавливаться.