In an event-driven service, a malformed event can reach consumers even when it cannot be processed. Message validation checks whether a message conforms to an expected schema before the producer sends it. Kafka brokers treat messages as raw bytes: they do not inspect their contents or enforce a format. section 6.4.1 section 5.1.1
With Schema Registry, a producer uses a registered schema to serialize and validate a message. A nonconforming message raises a producer-side exception and is not sent. The message carries a schema ID so a consumer can obtain the appropriate schema version and deserialize it. This protects the path only when clients are configured correctly: a misconfigured producer can still write invalid data to a topic. section 6.4.1
Figure 6.13 How a message, containing a schema, is serialized. Consumers decode a schema ID and use it to retrieve the schema from the Schema Registry, which they then use to deserialize the data.
The schema-ID flow shows how a consumer finds the schema needed to deserialize a message; the broker does not perform this check. section 6.4.1
A message that stops a consumer
A producer sends a message missing a required field. The broker accepts it, but a consumer cannot deserialize it. If the exception is unhandled and the offset remains uncommitted, restarting the consumer reads the same message and repeats the failure. Consumers should be tested against wrong-format messages and have a policy for handling them—for example, routing them to a monitored dead-letter topic. Operators can identify the offending offset from logs or browsing tools and reset a consumer offset with kafka-consumer-groups.sh when necessary. section 6.5.1
Validation rules are also a governance choice. Loosely defined schemas and optional fields can support early experimentation, but growing dependence on shared events calls for stronger schema validation and version control. Client-side validation reduces mistakes; it is not a broker-enforced guarantee. section 6.2.7 section 6.4.1
