A poison message is malformed, corrupted, or incompatible data that a consumer or processing stage cannot handle. If processing throws an exception before committing the offset, the same message is read again after restart, creating a failure loop. section 6.5.1 section 7.3.10
Treat poison messages as an operational and governance problem, not only as a serialization error:
- Identify the offending offset from logs or browsing tools, then reset the consumer group with kafka-consumer-groups.sh when necessary. section 6.5.1
- Test consumers against invalid formats, including messages with missing required fields rather than only obviously nonsensical payloads. section 6.5.1
- Redirect problematic sink messages to a dead-letter topic so processing can continue, while monitoring and alerting on that topic. section 6.5.1 section 7.3.10
- Plan schema changes across systems because field-level replication requires compatible schemas at each participating boundary. section 7.3.10
Schema change in a connector pipeline
A source system adds a column, but the Avro schema expected in Kafka does not change. Writing the record fails and the source connector stops because source connectors lack dead-letter-topic support. If a sink encounters an incompatible record, it can redirect the message to a DLT without interrupting the connector, provided operators monitor the resulting events. section 7.3.10
A durable policy distinguishes retryable failures from poison messages, defines offset-recovery procedures, and assigns ownership for reviewing dead-letter topics. Without active monitoring, redirected messages can become unnoticed data loss or processing delay. section 6.5.1 section 7.3.10
