skip to content

Which serializer configs select the subject naming strategy, and how do you set them differently for keys and values?

level: middleimportance: should knowfreq 50%

answer

  1. key.subject.name.strategy / value.subject.name.strategy
  2. value = FQ class name of strategy
  3. independent key vs value
  4. producer/serializer-side
  5. consumer resolves by schema ID, not subject

basics

~10 s

Use key.subject.name.strategy for the key schema and value.subject.name.strategy for the value schema. Each takes a fully-qualified strategy class such as TopicNameStrategy (default), RecordNameStrategy, or TopicRecordNameStrategy.

solid answer

~40 s

Subject naming is configured on the serializer with two independent properties: key.subject.name.strategy and value.subject.name.strategy. Each accepts the fully-qualified class name of a SubjectNameStrategy implementation: io.confluent.kafka.serializers.subject.TopicNameStrategy (default), RecordNameStrategy, or TopicRecordNameStrategy. They are separate so you can, for example, keep simple keys on the default TopicNameStrategy (orders-key) while putting multiple event types in the value via TopicRecordNameStrategy. The same setting names apply to Avro, Protobuf, and JSON Schema serializers. You can also implement a custom SubjectNameStrategy and pass its class name. These are producer-side configs because the producer's serializer registers/looks up the schema; consumers resolve schemas by the schema ID in the wire header, not by re-deriving the subject.

go deeper

for a junior

Recall the two config key names and the default value.

for a middle

Set them independently for key and value with correct FQ class names.

for a senior

Explain why they're producer-side and how consumers resolve schemas instead.

for a principal

Define org conventions and guard against mid-stream strategy changes forking history.

## The two config keys Schema-aware serializers expose two properties to choose how the subject is derived: - `key.subject.name.strategy` — governs the record **key** schema. - `value.subject.name.strategy` — governs the record **value** schema. They are deliberately independent because keys and values are different schemas with different needs. A very common setup: default strategy on the key (keys are usually a single simple type) and a record-aware strategy on the value (to allow multiple event types). ## Accepted values Each takes the **fully-qualified class name** of a `SubjectNameStrategy`: - `io.confluent.kafka.serializers.subject.TopicNameStrategy` (default) - `io.confluent.kafka.serializers.subject.RecordNameStrategy` - `io.confluent.kafka.serializers.subject.TopicRecordNameStrategy` - or your own implementation of the `SubjectNameStrategy` interface. These are the same across `KafkaAvroSerializer`, `KafkaProtobufSerializer`, and `KafkaJsonSchemaSerializer`. ## Where they live They are **producer/serializer-side** configs. The producer's serializer is what registers a schema (or looks one up) under a subject, so it needs the strategy. A consumer does **not** re-derive the subject to read data: each record's 5-byte header carries the exact schema ID, which the deserializer uses to fetch the schema. (Subject strategy can still matter on the consumer for features like `use.latest.version` that look up a subject's latest schema.) ## Example ``` key.subject.name.strategy=io.confluent.kafka.serializers.subject.TopicNameStrategy value.subject.name.strategy=io.confluent.kafka.serializers.subject.TopicRecordNameStrategy ``` This keeps key subjects as `<topic>-key` while letting the value side host multiple record types per topic. ## Pitfalls - Setting the strategy on the consumer expecting it to change how data is read — for normal reads it doesn't; the schema ID drives resolution. - Passing a short name instead of the fully-qualified class name. - Mismatched expectations between teams: changing value.subject.name.strategy changes which subjects get created, which can fork schema history if done mid-stream.

  • Are these configs producer-side or consumer-side?
    Primarily producer/serializer-side, since the serializer registers/looks up schemas by subject. Consumers normally resolve schemas via the schema ID in the wire header, though strategy can matter for latest-version lookups.
  • Can you mix strategies for key and value?
    Yes — they are independent properties. A common pattern is TopicNameStrategy for the key and TopicRecordNameStrategy/RecordNameStrategy for the value.

saying these in an interview costs you the question

  • Naming a single 'subject.name.strategy' config — it's split into key. and value. variants.
  • Saying consumers must set the same strategy to read data (they resolve by schema ID).
  • Passing a non-fully-qualified class name.

context

resolving links…