Что происходит с сообщениями после трех ретраев
Что проверяют
Знаете ли вы, что после исчерпания попыток сообщение не исчезает и не висит вечно, а должно иметь явный конечный маршрут. Заодно проверяют, различаете ли вы ошибки, которые имеет смысл повторять, и те, что упадут все три раза одинаково.
Как отвечать
Сначала уточните счёт: в настройках обычно задают число повторов, а не общее число доставок, поэтому «три ретрая» вполне может означать четыре попытки. Такое уточнение на собеседовании читается как опыт.
Дальше по существу. Когда попытки исчерпаны, обработчик ошибок передаёт запись восстановителю, и штатный исход один: отправить её в отдельный топик или очередь для неразобранного, приложив в заголовках причину, исходную тему, партицию и оффсет. Только после этого оффсет фиксируется и обработка идёт дальше.
В Spring для Kafka этим занимается обработчик ошибок по умолчанию вместе с публикацией в отдельный топик, в Spring AMQP ту же роль играет восстановитель, перекладывающий сообщение через обменник для неразобранного. Паузы задаются стратегией отката, разумно брать растущую задержку с разбросом, чтобы повторы не били в базу одновременно.
Важное различие напоследок: блокирующий повтор держит партицию, пока спит текущее сообщение. Для длинных пауз поэтому берут отдельные топики повторов, где ожидание не мешает остальным сообщениям.
Где спотыкаются
Повторяют всё подряд. Нарушение уникальности, невалидное тело, отказ авторизации от повтора не починятся: такие исключения помечают как неповторяемые, чтобы сообщение уходило в неразобранное сразу.
Не считают время блокировки. Пока обработчик спит между попытками, потребитель не опрашивает брокера, интервал превышается, группа перебалансируется, и те же сообщения выдаются заново поверх уже сделанной работы.
Заводят очередь неразобранного и забывают про неё. Без оповещений, просмотра и способа перезалить сообщения это просто место, где данные умирают тихо, а это хуже честного падения.