Event-driven architecture organizes communication around events: significant occurrences represented as data, produced by one component, published to a stream, and consumed asynchronously by other components. This creates near-real-time data flow between services and can connect legacy systems with newer applications without requiring major changes to existing systems. section 1.2
A Kafka-based implementation typically provides these capabilities and trade-offs:
- Store enterprise events in Kafka topics so multiple services can subscribe, process, and react to the same data. section 1.2
- Stream data in near real time, enabling immediate evaluation, workflow triggering, and communication across organizational systems. section 17.3.2
- Support large event volumes and reliable data flow through distributed systems, especially where frequent state changes make synchronous requests difficult to scale. section 17.3.2
- Require additional infrastructure and operational expertise; smaller teams may find the investment greater than the benefit. section 17.3.2
- Defer ad hoc analysis to tools or destinations such as Flink SQL, data lakes, and data warehouses because the distributed log is not a central queryable repository. section 17.3.2
Enterprise event flow
A user interaction, system update, or financial transaction becomes an event. An application publishes it to a Kafka topic, and other services subscribe to process it asynchronously. The same pattern can link a batch-oriented legacy system with modern services, allowing data to move between them without extensive changes to the legacy system. section 1.2
Figure 1.1 Kafka as the central nervous system for data in a company. Every event that takes place in the enterprise is stored in Kafka. Other services can react to these events asynchronously and process them further.
Use the architecture diagram to trace enterprise events into Kafka and follow asynchronous reactions by downstream services. section 1.2
