CCDAK Prep: Choosing Schema Registry Subject Naming Strategies — TopicNameStrategy vs RecordNameStrategy

A frequent CCDAK focus on Schema Registry is not the schema itself but rather "which Subject anchors compatibility." How Subjects are named depends on the naming strategy, and it strongly influences schema evolution flexibility, reusability, and operational simplicity.

This article compares the three core strategies (TopicNameStrategy, RecordNameStrategy, TopicRecordNameStrategy) and gives selection guidance and configuration examples for real-world scenarios. It is grounded in official documentation behavior and tuned for both exam prep and field application.

Foundations: The Role of Subjects and Naming Strategies

Schema Registry versions schemas per "Subject" and evaluates compatibility per Subject. Producers register the schema under a Subject during serialization and embed only the Schema ID in messages. Consumers fetch the schema by ID. In other words, the wire format does not contain the Subject name; the Subject is a conceptual boundary for registration and compatibility management.

A naming strategy is the rule that decides this Subject name. The three main options are TopicNameStrategy (default), RecordNameStrategy, and TopicRecordNameStrategy. The choice changes the compatibility scope (limited to one topic, or spanning multiple topics).

• Compatibility is evaluated per Subject (Backward/Forward/Full, etc.)
• The default strategy is TopicNameStrategy (<topic>-key / <topic>-value)
• RecordNameStrategy shares Subjects via the fully qualified record name and encourages reuse across multiple topics
• Schema IDs are unique across the registry. Since consumers resolve by ID, the Subject is a boundary for compatibility management

Relationship between Producer/Consumer and Subjects

Producer               Schema Registry                 Consumer
    |                          |                            |
    | 1) Serialize(value)      |                            |
    |--> subject resolved -----|                            |
    |    (by strategy)         |                            |
    |                          | 2) Register or lookup      |
    |-------------------------> |    schema under Subject    |
    |                          |    -> returns Schema ID    |
    | 3) Send record (ID+data) |                            |
    |-----------------------------------------------------> |
    |                          | 4) Fetch by Schema ID <----|
    |                          |    (subject not in wire)   |

TopicNameStrategy: The Default Strategy That Scopes Compatibility per Topic

TopicNameStrategy is the safest and default strategy. Subjects split into <topic>-key and <topic>-value, and compatibility is evaluated independently for each topic's key and value. Even when different topics share the same schema, their evolutions do not interfere with each other.

The benefit is that change impact is contained within topic boundaries. The downside is that even when the same schema is shared across topics, Subjects are fragmented, causing duplicate schema registrations and fragmented compatibility policy management.

• Subject examples: orders-value, orders-key
• Change impact is confined to a single topic
• Low reusability for shared schemas (re-registered per topic)
• A safe default early in operations or in environments with many independent development teams

Configuration example: apply RecordNameStrategy for values and TopicNameStrategy for keys

Properties p = new Properties();
p.put("bootstrap.servers", "localhost:9092");
p.put("key.serializer", "io.confluent.kafka.serializers.KafkaAvroSerializer");
p.put("value.serializer", "io.confluent.kafka.serializers.KafkaAvroSerializer");
p.put("schema.registry.url", "http://localhost:8081");

// 既定はTopicNameStrategyだが、明示も可能
p.put("key.subject.name.strategy", "io.confluent.kafka.serializers.subject.TopicNameStrategy");

// 値だけRecordNameStrategyに切り替える例（混在可）
p.put("value.subject.name.strategy", "io.confluent.kafka.serializers.subject.RecordNameStrategy");

// 本番では自動登録を止め、最新利用へ切り替える選択肢もある
p.put("auto.register.schemas", false);
p.put("use.latest.version", true);

// 確認: 現在のSubject一覧
// curl http://localhost:8081/subjects
// 例: orders-key, orders-value, com.example.OrderCreated などが列挙される

RecordNameStrategy: Reuse Across Topics by Record Name

RecordNameStrategy determines the Subject from Avro's fully qualified name (namespace.name) or the message name in Protobuf/JSON Schema. As a result, even when the same record is used across multiple topics, it consolidates into a single Subject, and compatibility policies are concentrated in one place.

The benefits are promoting schema reuse and centralizing compatibility policy. On the other hand, carelessly using the same fully qualified name for a different schema can cause collisions. Solid namespace design, naming conventions, and care to avoid reusing record names across keys/values are essential.

• Subject example: com.example.events.OrderCreated
• Unifies compatibility across multiple topics
• Risk of collisions if namespace design is weak
• Fits organizations that emphasize a shared event/schema foundation

TopicRecordNameStrategy and Comparing the Three Strategies

TopicRecordNameStrategy creates a Subject by combining the topic name with the fully qualified record name. It preserves topic-boundary independence while making it easy to distinguish different record names within the same topic. It is a balanced choice when adopting multi-event topics.

The table below organizes the three strategies by viewpoint. For CCDAK, focus on the often-asked points: "the scope of compatibility" and "when reuse is effective."

• Subject example: orders-com.example.events.OrderCreated
• Easy to manage for multi-event topics
• Less reusable than RecordNameStrategy, but lower collision risk

Compatibility and Evolution: The Subject Is the Boundary

Compatibility levels (Backward/Forward/Full/Transitive, etc.) can be set as a global default and overridden per Subject. Regardless of the strategy, evaluation ultimately happens against "that Subject." Therefore, choosing RecordNameStrategy raises the responsibility of maintaining backward compatibility against a single Subject shared by multiple topics.

The combination of auto.register.schemas=false and use.latest.version=true helps with pre-registration and phased rollouts in production. Since producers do not autonomously create new schemas, you can more easily prevent compatibility breakage.

• Compatibility is per Subject. Strategy choice = boundary design
• Same-name record collisions surface most easily with RecordNameStrategy
• Key and value are separate Subjects; you can configure different strategies for each
• In large organizations, build naming conventions and review into the process

Practical Checklist and Migration Thinking

Inventory your current topics and events, and check which are shared across multiple topics. If sharing is heavy, RecordNameStrategy is natural; if topics are independent, TopicNameStrategy fits better. For multi-event topics, also consider TopicRecordNameStrategy.

Begin migration with new producer settings and leave existing messages as is. Since the wire format resolves via Schema ID, consumers are not affected. However, old and new Subjects coexist after migration. Monitor compatibility policies and the growth in Subject count on the Registry side.

• When using different strategies for key/value, avoid reusing the same record name
• Tighten namespaces (e.g., com.company.domain.event)
• In production, turn off auto.register.schemas and build a pre-registration pipeline
• During migration, strengthen monitoring of Subject lists and compatibility violations

Check Your Understanding

Frequently Asked Questions