What is a 'subject' in Schema Registry, and how does it differ from a global schema ID and a version?
answer
- subject = named version bucket (orders-value)
- version = per-subject 1,2,3
- global ID = registry-wide unique, monotonic
- wire format carries global ID, not subject/version
- TopicName vs RecordName strategies
basics
~20 sA subject is a named scope (usually one per topic, like orders-value) under which schemas are registered and versioned (1, 2, 3...). A global schema ID is a single number that uniquely identifies one physical schema across the whole registry, independent of subjects and versions.
solid answer
~40 sA **subject** is the unit of versioning and compatibility in Schema Registry — a named bucket of schema versions. With the default `TopicNameStrategy`, each topic produces two subjects: `<topic>-key` and `<topic>-value`. Within a subject, each newly registered schema gets a sequential **version** (1, 2, 3...) and compatibility checks are evaluated against prior versions of that subject. Separately, every distinct physical schema gets a **global schema ID** that is unique and monotonic across the entire registry, regardless of how many subjects reference it. The wire format carries the global ID, not the subject or version. So the same schema registered under two subjects shares one global ID but has its own version number in each subject. Subject naming can be changed via the value/key subject name strategy (TopicName, RecordName, TopicRecordName) for advanced multi-schema-per-topic setups.
go deeper
Know a subject is usually one per topic (orders-value) and schemas under it are versioned 1,2,3.
Distinguish subject vs version vs global ID and name the default key/value subjects.
Explain dedup of identical schemas to one global ID and when to use RecordName/TopicRecordName strategies.
Design subject strategies for multi-type topics and reason about compatibility scope vs storage identity trade-offs.
## Three distinct identifiers Newcomers conflate three things that are deliberately separate: 1. **Subject** — a *name* that scopes versioning and compatibility. Think of it as a folder. Default subject for a topic's values is `<topic>-value`; for keys, `<topic>-key`. 2. **Version** — a per-subject sequence number (1, 2, 3...). Each time you register a *new, distinct* schema under a subject, it gets the next version. Re-registering an identical schema returns the existing version (it is idempotent). 3. **Global schema ID** — a registry-wide unique integer for one physical schema. It is **monotonic** (assigned in increasing order) and **global** (not reset per subject). ## Why three, not one - **Compatibility** is meaningful only within a subject — you evolve `orders-value` over time, and the registry checks version N+1 against earlier versions of *that* subject. - **Storage and the wire format** want a single canonical ID per physical schema so the same schema is stored once and referenced by 4 bytes. That is the **global ID**. - A schema can be reused across subjects; deduplicating by global ID avoids storing it twice. ## How they map Example timeline: - Register schema A under `orders-value` → subject `orders-value` version **1**, global ID **101**. - Register schema A again under `shipments-value` → subject `shipments-value` version **1**, **same** global ID **101** (deduplicated). - Evolve `orders-value` with schema B → `orders-value` version **2**, global ID **102**. So version numbers restart at 1 per subject, while global IDs keep climbing across the whole registry. ## Subject naming strategies The mapping from a record to a subject is controlled by a **subject name strategy** (set via `value.subject.name.strategy` / `key.subject.name.strategy`): - **TopicNameStrategy** (default): `<topic>-key` / `<topic>-value`. One schema type per topic. - **RecordNameStrategy**: subject = the Avro record's fully-qualified name. Lets one topic carry multiple unrelated record types. - **TopicRecordNameStrategy**: `<topic>-<recordFQN>`. Multiple record types per topic but still scoped to the topic. ## Edge cases - Registering a byte-identical schema is idempotent: same version, same global ID returned. - Deleting a subject version is a soft (or permanent/hard) delete via REST; it does not necessarily free the global ID, which other subjects may still reference. - The consumer's deserializer never needs the subject to decode — it uses only the global ID from the wire header. The subject matters for *governance* (compatibility), not for *decoding*.
- What are the default subject names for a topic called 'orders'?orders-key and orders-value, produced by the default TopicNameStrategy (key and value are versioned and checked for compatibility independently).
- Can one global schema ID appear in two different subjects?Yes. If the same physical schema is registered under multiple subjects, it is deduplicated to a single global ID, but it has its own version number within each subject.
saying these in an interview costs you the question
- Saying the wire format carries the subject name or version (it carries the global ID).
- Claiming versions are global — they are per-subject.
- Thinking each topic always has exactly one subject (keys and values are separate, and strategies can change this).