Compare RecordNameStrategy and TopicRecordNameStrategy. What subject does each produce and when would you choose one over the other?

## The problem these solve The default `TopicNameStrategy` maps a topic's value to a single subject (`<topic>-value`). If you try to publish **two genuinely different record types** to one topic, both land in the same `-value` subject and the registry treats them as evolutions of one another — they will fail compatibility checks. The record-aware strategies break the subject out of the topic so multiple types can coexist. ## RecordNameStrategy `io.confluent.kafka.serializers.subject.RecordNameStrategy` derives the subject from the **fully-qualified record name** of the schema itself: - Avro: `<namespace>.<name>` (e.g. `com.acme.OrderCreated`) - Protobuf: the fully-qualified message name - JSON Schema: the schema's title / `$id`-derived name The topic is **not** part of the subject. Consequences: - The **same type used in many topics shares one subject** and therefore one evolution timeline and one set of compatibility rules. Define `com.acme.Money` once; every topic that carries it uses subject `com.acme.Money`. - You can put many types in one topic — each maps to its own subject by its FQN. ## TopicRecordNameStrategy `io.confluent.kafka.serializers.subject.TopicRecordNameStrategy` derives the subject as **`<topic>-<fully-qualified-record-name>`** (e.g. `orders-com.acme.OrderCreated`). It combines both axes: - Multiple types per topic: yes (FQN disambiguates). - Evolution is **scoped per (topic, type)** pair, so the same record type can evolve differently in two different topics without conflicting. ## Choosing between them | Goal | Strategy | |------|----------| | One topic, one type (default) | TopicNameStrategy | | Many types per topic, ONE global lineage per type | RecordNameStrategy | | Many types per topic, lineage isolated per topic | TopicRecordNameStrategy | Rule of thumb: **RecordNameStrategy = sharing** (a type means the same thing everywhere — maximum reuse, but a breaking change ripples to every topic using it). **TopicRecordNameStrategy = isolation** (each topic owns its copy of the type's lineage — safer blast radius, but the same logical type can drift between topics and you register more subjects). ## Edge cases - Both are typically configured on `value.subject.name.strategy`; keys can use them too but multi-type keys are rare. - With record-name strategies, the consumer's deserializer must be able to handle whichever type arrives — schema ID in the wire header resolves it, but downstream code must branch on type (e.g. an Avro union or `SpecificRecord` dispatch). - RecordNameStrategy makes a single schema change a cross-topic event: governance and ownership of that subject become organizational concerns. - A renamed namespace silently creates a *new* subject (new lineage), losing the old compatibility history.