Если использовали DLQ, объясните критерии невалидности, состав безопасного сообщения и порядок фиксации обработки. Количество ошибок назовите только по реальным метрикам.
Вы перекладывали невалидные сообщения в отдельный топик и продюсировали или как? Много таких сообщений было?
Если использовали DLQ, объясните критерии невалидности, состав безопасного сообщения и порядок фиксации обработки. Количество ошибок назовите только по реальным метрикам.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Если использовали DLQ, объясните критерии невалидности, состав безопасного сообщения и порядок фиксации обработки. Количество ошибок назовите только по реальным метрикам.
Постоянно неверные сообщения не стоит бесконечно повторять, но временный отказ зависимости не делает payload невалидным. Для отдельного топика сохраняйте идентификатор, причину и сведения, необходимые для исправления и replay, не размножая секреты. Между публикацией в DLQ и commit offset тоже возможен сбой, поэтому предусмотрите безопасный повтор и аудит.