Kafka brokers transfer messages as bytes without interpreting their contents. A producer serializes business data before sending it; a consumer deserializes those bytes into objects or other structures it can process. The two clients must agree on the format. The broker cannot detect a mismatch for them. section 3.1.4
Deserialization sits in the consumer’s polling cycle: request messages, receive a batch, deserialize it, run application logic, and commit an offset. Committing records where consumption should resume; it does not prove that processing succeeded. section 4.2
Matching client configuration
If a producer serializes integer keys and string values, its consumer needs the corresponding integer key and string value deserializers. These are separate client settings, not a format contract checked by the broker. A mismatch surfaces as a runtime error. section 3.1.4
A malformed message can otherwise stop a consumer from making progress. Deserialization error handling may log the failure, retry, or send the message to a dead-letter queue. Because brokers do not deserialize messages, they also cannot validate their structure or route them by content; content-based routing requires a service that reads and deserializes messages first. section 4.3.4 section 5.2.3
Schema-based messages add a way to manage format agreement. With Schema Registry, the producer includes a schema ID alongside serialized data, rather than sending the schema itself. A suitably configured consumer uses that ID to retrieve or reuse the correct schema version and deserialize the message. Validation still occurs in clients: an incorrectly configured producer can send invalid data that the broker accepts. section 6.4.1
