6 Defining data contracts

We’ve looked at the fundamentals of Kafka and its real-world fit, so let’s turn to a practical question: how can we define events and express them as durable, evolvable data contracts. To address this, we need to set event boundaries and granularity, compare state versus delta events (and when each fits), and map domain events to Kafka messages without losing business meaning. We’ll explore the tools and techniques for managing contracts over time: type evolution and compatibility, format choices, ownership, and how teams communicate changes. Then we can turn to implementation with Schema Registry and survey practical alternatives. This should set you up with a clear path from whiteboard models to production-ready schemas that teams can rely on.

6.1 How Kafka handles event structure

6.2 Designing events

6.2.1 Challenges in event design

6.2.2 Fact and delta events: Representing state changes

6.2.3 Composite, atomic, and aggregate events: Representing event structure

6.2.4 Pulling state on notification

6.2.5 Evolution of types

6.2.6 Mapping events to Kafka messages

6.2.7 Data strategies for the Customer 360 ODS

6.3 Event governance

6.3.1 Data formats

6.3.2 Selecting a data format for the Customer 360 ODS

6.3.3 Data ownership

6.3.4 Organizing data and communicating changes

6.3.5 Designing events for the Customer 360 ODS

6.4 Schema Registry

6.4.1 Schema Registry in Kafka ecosystem

6.4.2 Registering schemas

6.4.3 A concept of subject

6.4.4 Compatibility rules

6.4.5 Alternatives to Schema Registry

Summary