Real-time processing handles events as they occur with minimal delay, so a business can act while the information is still useful. In an e-commerce system, publishing an order event lets inventory, payment, shipping, and analytics react independently rather than relying on direct integrations between every service. The same need for a quick reaction appears in fraud detection and predictive maintenance. section 5.2.9 section 1.0
Kafka moves events between producers and consumers at low latency; it does not interpret the data or perform analytics by itself. A processing application consumes events, applies logic, and can publish results for other consumers. Kafka Streams provides Java applications with filtering, transformation, aggregation, and other processing functions. Other streaming frameworks can also process data received from Kafka. section 5.1.4 section 8.7
Figure 5.8 The fraud detection application acts as a producer and a consumer for Kafka topics. It reads messages from the Transactions topic, processes them, and sends the output results to the Fraudulent Transactions topic.
The fraud-detection flow shows the boundary clearly: an application consumes transaction events from one Kafka topic, processes them, and produces results to another topic. section 5.1.4
Low latency is a requirement to establish, not an automatic reason to stream everything. Daily ETL can be more efficient when immediate analysis is unnecessary; reporting and nightly reconciliation may naturally run in batches. Conversely, forcing bulk uploads onto a continuous Kafka stream creates work: a consumer must gather records across partitions, choose batch boundaries despite late arrivals, and handle partial failures and retries. section 5.1.4 section 5.2.9
Design the processing mode around the required response time and the event workflow. If multiple events must be considered together, plan how to correlate them; if retries could repeat an event, account for whether consumers are idempotent. Streaming frameworks offer options such as stateful operations, time windows, and exactly-once processing semantics, but those choices belong to the processing design rather than to the broker alone. section 10.1.3 section 8.7
