Poison messages

Poison-сообщения падают при каждой попытке из-за битого payload, несовместимости схемы, отсутствующих данных или бага в логике — а не из-за transient-сбоев инфраструктуры. Без детекции они жрут CPU, блокируют partition и запускают retry-штормы, усиливающие аварии.

Обнаруживайте poison по счётчику попыток, классификации ошибок и circuit breaker при повторяющихся одинаковых сбоях. Быстро переносите в DLQ после небольшого фиксированного лимита. Исправляйте через версионирование схемы и валидацию на входе до постановки в очередь.

На интервью: разделите transient и poison сбои, объясните, как одно плохое сообщение стопорит очередь, и опишите нужные алерты.

Типовые ошибки: бесконечный retry ошибок валидации; нет проверки совместимости схем producer и consumer; общая политика retry для всех ошибок; операторы не видят проблему среди обычных retry.

Компромисс — гибкость против сложности: знайте, когда достаточно более простого пути.

Чеклист:

• Классифицируйте ошибки: transient или permanent.
• Ограничьте retry и быстро направляйте poison в DLQ.
• Валидируйте payload до enqueue.
• Алерт на повторяющиеся одинаковые сигнатуры сбоев.