When services exchange Kafka events instead of calling APIs, consumers still need to know what a message means and what data to expect. A data contract makes those expectations explicit between producer and consumer. It treats event data as something to model, validate, and evolve across service boundaries. section 1.5 section 6.0
A complete event contract has three parts:
- Structure: a schema defines fields, types, and constraints. JSON Schema, Avro, and Protobuf are possible formats. section 6.2.6
- Channel: a Kafka topic carries the event. section 6.2.6
- Trigger: an explanation of when and why the event is sent. This is typically recorded during analysis rather than mapped directly to a Kafka concept. section 6.2.6
Customer 360 event contracts
For a Customer 360 operational data store, a profile service emits full-profile fact events because updates are infrequent; a transaction service emits facts about immutable transactions. Choosing JSON for the payload does not, by itself, settle the contract. The teams must also agree on event structures, topics, and ownership. Loosely defined schemas and optional fields can help early experimentation, but growing consumer reliance calls for stronger validation and version control. section 6.2.7
The producer team owns the contract because it holds the domain knowledge behind the data, but consumers need a way to review it and request changes. A shared, version-controlled schema repository makes definitions accessible; release notifications let consumers update their code or rely on backward compatibility. Keeping analytical event specifications disconnected from implementation risks inconsistent structures and harder event discovery. section 6.3.3 section 6.3.4 section 6.2.6
Schema Registry supports contract evolution by registering new immutable schema versions and checking compatibility. Backward or forward compatibility can let old and new versions coexist; unavoidable breaking changes need a migration plan, such as phased deployments or transformations. Kafka brokers do not enforce schemas: producers and consumers must implement the relevant checks. section 1.5.1 section 6.7
Figure 1.7 Working with Schema Registry: schemas are managed by a separate Schema Registry cluster; messages carry only a schema ID, which clients use to fetch (and cache) the writer schema.
The diagram shows how messages carry a schema ID rather than the schema itself. Clients use that ID to retrieve and cache the writer schema from a separate Schema Registry cluster. section 1.5.1
