apache kafka - Confluent Schema Registry Avro Schema -

hey use confluent schema registry avro serializers: documentation says: not use same schema multiple different topics

can explain me why? reasearch source code , stores schema in kafka topic follows (topicname,magicbytes,version->key) (schema->value)

therefore don't see problem of using schema multiple times expect redundancy?

i think referring comment in documentation:

we recommend users use new producer in org.apache.kafka.clients.producer.kafkaproducer. if using version of kafka older 0.8.2.0, can plug kafkaavroencoder old producer in kafka.javaapi.producer. however, there limitations. can use kafkaavroencoder serializing value of message , send value of type avro record. avro schema value registered under subject recordname-value, recordname name of avro record. because of this, same avro record type shouldn’t used in more 1 topic.

first, commenter above correct -- refers old producer api pre-0.8.2. it's highly recommended use new producer anyway better implementation, doesn't depend on whole core jar, , client maintained going forward (there isn't specific timeline yet, old producer deprecated , removed).

however, if using old producer, restriction required if schema 2 subjects might evolve separately. suppose did write 2 applications wrote different topics, use same avro record type, let's call record. both applications register it/look under subject record-value , assigned version=1. fine long schema doesn't change. lets application needs add field. when so, schema registered under subject record-value , assigned version=2. fine application a, application b has either not been upgraded handle schema, or worse, schema isn't valid application b. however, lose protection schema registry gives -- other application publish data of format topic used application b (it looks ok because record-value has schema registered). application b see data doesn't know how handle since not schema supports.

so short version because old producer subject has shared if use same schema, end coupling 2 applications , schemas must support. can use same schema across topics, suggest not doing since couples applications (and development, teams developing them, etc).