Event-driven architecture (EDA) organizes a system around the production, consumption, and handling of events. When something changes, a service publishes a notification to an intermediary channel; interested services consume it and react independently. Unlike a request-response workflow, the publisher does not need to call each recipient directly. section 1.1.1 section 1.1
A customer address changes
Rather than calling a customer service whenever it needs an address, an order service listens for address-change events and keeps a local copy. Other interested services can receive the same notification. If the order service is temporarily offline, it can process the notification when it returns; if the customer service is offline, the order service can continue using its local copy. section 1.1.1
Figure 1.2 The EDA style of communication: systems communicate by publishing events that describe changes, allowing others to react asynchronously.
The diagram shows the central change in interaction: services publish changes for other services to handle asynchronously instead of calling them directly. section 1.1.1
Kafka can provide the shared channel: producers publish events, and multiple consumers react. Retaining events for a configured period lets a subscriber recover from a failure and reprocess them. This decoupling supports independent services, but it does not remove consistency problems. Designs must account for eventual consistency, idempotency, out-of-order events, and whether messages actually reach their consumers. section 1.0 section 1.7.1 section 1.1 section 5.1.1
Events also become contracts between systems: their structure and meaning need modeling, validation, and versioning. Kafka is one possible backbone, not a requirement for EDA. Choose it against the workload’s needs; it is strong for high-rate, low-latency processing of small messages, but may be a poor fit for strict ordering, batch transfers, or random data access. section 1.5 section 5.1.1 section 5.5
