TopicRecordNameStrategy names a schema subject from both the Kafka topic and the record schema. It permits multiple event types in one topic while isolating each record type’s schema within that topic. section 3.3.3 section 3.3
Use this strategy when you need both kinds of flexibility:
- Place multiple logically related record types on one topic. section 3.3.3
- Use different schema versions for the same record type on different topics. section 3.3.3 section 3.6
- Accept that the strategy does not restrict a topic to a fixed set of record types; schema references are the alternative when that policy is required. section 3.3.3 section 3.6
Separate legacy and current purchase schemas
An interactions topic can contain the current CustomerPurchaseEvent schema alongside other customer events, while a legacy purchases topic can contain an older CustomerPurchaseEvent schema with different fields. TopicRecordNameStrategy keeps compatibility checks scoped to each topic. Configure the producer and consumer with the strategy for values; configure keys only when keys use schemas, and key and value strategies do not need to match. section 3.3.3 section 3.3
Java configuration
Set the serializer and deserializer subject strategies explicitly: producerConfig.put(KafkaAvroSerializerConfig.VALUE_SUBJECT_NAME_STRATEGY, TopicRecordNameStrategy.class); consumerConfig.put(KafkaAvroDeserializerConfig.VALUE_SUBJECT_NAME_STRATEGY, TopicRecordNameStrategy.class);. Apply the corresponding key settings only when serialized keys use schemas. section 3.3.3 section 3.3.3
Figure 3.8 TopicRecordNameStrategy allows different schemas for the same domain object across different topics.
Compare the same record type across topics: TopicRecordNameStrategy allows topic-A and topic-B to register different schemas for that type. section 3.3.3

