A subject groups schema versions for an event domain while separating that domain model from the Kafka topic arrangement. Organizations can map one event type to one topic or group related event types in a shared topic. section 6.4.3
When an event structure changes, the Schema Registry creates a new subject version. Compatibility rules belong to the subject and determine whether the new schema can be registered. section 6.4.3 section 6.4.4
Subject design makes the event-to-topic relationship an explicit architectural choice:
- TopicNameStrategy associates schema evolution with a specific Kafka topic, such as CLIENTS, keeping compatible schema versions together. section 6.4.3
- Backward compatibility lets upgraded consumers read earlier messages, permitting removed fields and newly added fields with defaults. section 6.4.4
- Rejected incompatible registrations protect consumers, although coordination becomes harder when many independent teams consume the subject. section 6.4.4
Client events on CLIENTS
An Avro ClientEvent carries an event identifier, event type, timestamp, client identifier, and client name. Published to CLIENTS with TopicNameStrategy, its schema versions are grouped under the topic-associated subject. section 6.4.3
Listing 6.10 An example of the client event in Avro format
{
"type": "record",
"name": "ClientEvent",
"namespace": "com.example",
"fields": [
{
"name": "eventId",
"type": "string",
"doc": "Unique identifier for the event"
},
{
"name": "eventType",
"type": "string",
"doc": "Type of event (e.g., 'ClientCreated', 'ClientUpdated')"
},
{
"name": "timestamp",
"type": "long",
"logicalType": "timestamp-millis",
"doc": "Event timestamp in milliseconds"
},
{
"name": "clientId",
"type": "string",
"doc": "Unique identifier for the client"
},
{
"name": "clientName",
"type": "string",
"doc": "Name of the client"
}
]
}
Inspect the ClientEvent schema to see the concrete event structure governed by a subject. section 6.4.3
