A customer changes an address. Rather than requiring every interested service to call the customer service, the service can publish an event: an immutable, timestamped record of what happened. An event signals a business occurrence; its context makes that occurrence meaningful. section 1.1.1 section 6.2.1
In an event-driven architecture, a producer sends the notification to a channel, and subscribers process it independently. Billing, analytics, and order services can each receive the address change without the producer calling them directly. Asynchronous delivery lets an unavailable subscriber process the notification later. Kafka retains events for a configured duration so a subscriber can reprocess them after a failure. section 1.4.1 section 1.7.1
An event describes an occurrence in the application domain; a Kafka message is its physical representation. Producers send messages to topics, and consumers subscribe to topics. A useful data contract specifies the event’s structure, its channel, and when and why it is emitted. Kafka maps the structure to a schema and the channel to a topic, but the triggering rule generally remains a written specification. section 2.2 section 6.2.6
Decisions about event boundaries affect both meaning and reuse:
- Choose granularity: a profile update might carry the entire profile, a changed entity such as an address, or only one changed attribute. section 6.2.1
- Define field names, types, and metadata such as version or tracking identifiers; decide whether technical attributes belong in the event structure or separate metadata. section 6.2.1
- Let business requirements determine which notifications are needed. The producer owns the event structure and should make it reusable for its known potential consumers. section 1.4.1
Figure 6.3 Each entity is mapped to a distinct event. For example, if an address changes, only an AddressUpdated event will be sent, without any information about the UserProfile or SocialAccount.
The distinct-entity design illustrates one granularity choice: an address update carries address information without the rest of the user profile. section 6.2.1
Schemas give producers and consumers a shared account of fields, types, and constraints. JSON Schema, Avro, and Protobuf are possible formats. Keep business definitions and implemented schemas aligned: disconnected specifications can leave events hard to discover or give analytical and technical descriptions different structures. Kafka is a strong fit for high-rate, small-message event processing, but requirements such as strict ordering or random data access may call for another approach. section 6.2.6 section 5.5
