...

• We discarded the idea that the validation policy plugin class could be defined per-topic, as a single per-broker policy could act as a facade to different policies specific to topics (e.g. different registries)

• We discarded the idea to add an optional filed (eg schema id) to the kafka protocol Produce API, as that would require new clients not just serdes. Moreover, KIP-467 makes this approach look unnecessary.

• It remains possible to implement a Kafka Streams functionality that filters a topic that clients write to, into another topic with validated messages (and maybe a “dead letter” topic for invalid ones). Such an alternative approach doesn’t provide any direct feedback to the client producer in the response. It also doesn’t require the broker to execute third party code semantically coupled with the clients, at the price of having an extra “moving part” (the Streams app) which contains such logic. Moreover, the topic-to-schema mapping must map both input topic and destination topic to the same schema.

• We discarded having a boolean topic config to control per-topic enablement of the validation, when a policy is specified at the broker level, in favor of a string topic config whose value that can be consumed by the policy, as per the sample below.

Sample test policy

Here is a sample of a validfation policy that we may use for the unit tests suite.

// Example RecordValidationPolicy implementation that checks record headers. Only records
// containing a header with a key that matches the 'record.validation.policy' property of
// the topic are accepted.
publicclassRequireHeaderValidationPolicyimplementsRecordValidationPolicy {

@Override
publicvoidconfigure(Map<String, ?> configs) {
  // This example doesn't use any of the broker's configuration properties.
}

@Override
publicvoidclose() throwsIOException {
  // This example doesn't need to perform any cleanup when the broker is shutdown.
}

@Override
publicvoidvalidate(TopicMetadatatopic, RecordProxyrecord) throwsInvalidRecordException {
  // Do any of the record headers have a key matching the 'record.validation.policy'
  // property of the topic being produced to?
  if (!record.headers().stream().filter(h->h.key().equals(topic.validationPolicy())).findFirst().isPresent()) {
  thrownewInvalidRecordException(
   String.format("Topic %s requires records to contain a header with key: %s",
   topic.topicIdPartition().topic(), topic.validationPolicy()));
  }
}

@Override
publicRecordIntrospectionHintsgetHints() {
// RequireHeaderValidationPolicy only requires access to the record headers.
// 0 is returned for the key/value portions of the record as this policy
// doesn't inspect these fields. This avoids any potential overhead in the
// broker parsing the record to find fields that the policy doesn't make use of.
returnnewRecordIntrospectionHints() {
  @Override
  publicbooleanaccessHeaders() {
   returntrue;
  }

  @Override
  publiclongaccessKeyBytes() {
   return0;
  }

  @Override
  publiclongaccessValueBytes() {
   return0;
  }
};
}

}