iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
TopicRecordNameStrategy is a Confluent Schema Registry subject naming strategy that combines a Kafka topic name with a record’s fully qualified name. For example, a value record named com.example.OrderCreated in the orders topic is registered under orders-com.example.OrderCreated. Because each topic-and-record pair gets its own subject, a topic can carry multiple record types without putting them all in one compatibility sequence.
What subject does TopicRecordNameStrategy create?
For a record published to a Kafka topic, the subject format is <topicName>-<recordName>, where the record name is fully qualified. Confluent’s documentation defines this naming rule.
For example, if the topic is orders and the Avro record fullname is com.example.OrderCreated, the subject is orders-com.example.OrderCreated. The same record fullname published to another topic gets a different subject, giving it an independent compatibility history.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →How does it compare with the other subject naming strategies?
| Strategy | Subject format | Compatibility boundary | Typical use |
|---|---|---|---|
TopicNameStrategy (default) |
<topic>-key or <topic>-value |
Topic | A topic is intended to carry one logical schema. |
RecordNameStrategy |
<fully-qualified-record-name> |
Record type across topics | The same record type should share one compatibility lineage across topics. |
TopicRecordNameStrategy |
<topic>-<fully-qualified-record-name> |
Record type within a topic | A topic carries multiple record types, with evolution scoped to each topic-record pair. |
Confluent describes TopicNameStrategy as the default and as implicitly expecting messages in a topic to conform to one schema. The record-based strategies are useful when a topic-only boundary is not the right fit. See Confluent’s subject naming strategy documentation and Schema Registry concepts.
#1 Best Overall
How do you configure TopicRecordNameStrategy?
Set the fully qualified implementation class in the client configuration. Use the value property for record values and the key property for keys:
value.subject.name.strategy=io.confluent.kafka.serializers.subject.TopicRecordNameStrategy
key.subject.name.strategy=io.confluent.kafka.serializers.subject.TopicRecordNameStrategyConfigure only the key or value property if the other side should keep a different strategy. These are client-side properties: a broker-side subject strategy does not automatically configure producers or consumers. Apply matching settings to each producer and consumer that serializes or deserializes the relevant key or value. Consult Confluent’s serializer configuration reference.
What does it mean for compatibility and schema evolution?
Schema Registry associates compatibility checks and schema versions with subjects. With this strategy, the subject boundary includes both the topic and the record fullname. That allows several record types in one topic to have separate compatibility sequences. It also means the same record fullname can evolve independently on two different topics.
Recommended Free Tools
Choose this strategy when the topic is intentionally a heterogeneous event stream and a record type may need topic-specific evolution. If each topic should have one stable schema, the default TopicNameStrategy is simpler. If a record type should have a single compatibility lineage everywhere it appears, consider RecordNameStrategy.
Rank #3
Why is Schema Registry looking for a different subject?
A mismatch often occurs when a producer registers a schema under one subject formula but a consumer or another producer is configured to use another. Check the key and value subject-name settings on every client, then compare the configured strategy with the subject names already registered in Schema Registry.
Changing an existing flow from TopicNameStrategy changes the subject names producers register and consumers look up. Treat it as a coordinated schema and client configuration change: check the new subjects and compatibility behavior, configure serializers and deserializers consistently, and plan the rollout for your deployment. The exact migration order depends on how your producers, consumers, and registered schemas are managed.
What is the Protobuf reference-subject caveat?
For Protobuf, account for reference.subject.name.strategy as well. Confluent documents this additional setting because Protobuf automatically registers schema references. Avro and JSON Schema references are typically registered manually, so their reference subject can be selected explicitly. See Confluent’s Schema Registry documentation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
