На днях прорабатывал поведение сервиса при отказах, и задумался, как это правильно делать.

Вот есть сервис, он что-то делает, к примеру, читает сообщения из очереди Кафки, как-то их обрабатывает и записывает результат в какую-то СУБД. И вот, допустим, он не смог прочитать сообщение из Кафки, сетка там, к примеру, отказала, или Кафка призадумалась, не важно.

Что делает в такой ситуации благовоспитанный сервис? Правильно, ждет немножко и пробует ткнуться ещё раз. Если не помогло, то и еще раз. Особо интеллигентные сервисы умеют даже варьировать время ожидания между попытками. Но все это хорошо, когда отказ внешних подсистем относительно кратковременный.

А если связанный компонент прилег надолго - то как должен вести себя сервис в части повторных попыток? Продолжать долбиться до бесконечности и гадить в логи, как отвергнутый ухажер мучает соседей красавицы, источая гнусавые серенады под её окном?
Или все же через какое-то время он должен понять и признать, что его отвергли, смириться с этим и перестать изображать из себя сумасшедшего дятла?
А как потом правильно вывести сервис из депрессии и вернуть к активной жизни?

В общем, я пока принял половинчатое решение - завел конфигурируемую политику повторных попыток при отказах, в которую включил ограничение на число повторных попыток. При превышении этого числа сервис расстраивается и прекращает работу. А дальше кубер запустит на освободившееся место новый под и серенада продолжится. Кардинально ничего не изменяется, но, по крайней мере, дятлы будут сменять друг друга. Посмотрим, как эта штука будет вести себя в реальной жизни, а там подумаем как улучшить.

А как вы реализуете повторы при отказах?
#мысливслух