Before designing Kafka topics, identify the business state changes that other participants need to know about. An event catalog maps those changes to the workflows they serve. It gives business and technical teams a shared view of what happened, who publishes the event, and who is expected to react. section 10.1.2 section 10.5
For each business event, record:
- A clear, past-tense name and a plain-language business meaning. section 10.1.2
- The producer, interested consumers, trigger condition, and expected reaction. section 10.1.2
- The business owner who validates its meaning and a high-level account of required event data. section 10.1.2
Loan processing
A loan application can produce a LoanApplicationSubmitted event for the risk service. Later state changes include completion of the risk assessment and the checks that lead to an approval decision. Cataloging each event makes the handoffs and expected reactions explicit before choosing topic settings or a wire format. section 10.1.2 section 10.5
The catalog also supports governance and discovery. Include technical topics that do not represent business events, such as intermediate topics created when a stream is repartitioned, so they remain visible for compliance, monitoring, and operations. Keep event definitions aligned with schemas and code: disconnected specifications can obscure available events and allow data structures to diverge. Document schema changes, check compatibility, and communicate changes across teams. section 10.1.3 section 6.2.6
