Apache Kafka combines messaging, durable event storage, data integration, and stream processing, so teams can use it as the central event system for many applications.
2
Tiered storage moves older Kafka data to object storage while keeping the Kafka API unchanged, making long-term retention cheaper and reducing broker rebalancing to the local hot set.
3
Kafka can connect real-time machine learning training, scoring, monitoring, and replayable data with other systems, although batch processing and some model-serving features still need separate tools.
Summary
Kai Waehner explains why Apache Kafka is more than a messaging system. Kafka stores ordered, timestamped events, lets producers and consumers operate independently, and supports retention policies that range from hours to years. Tiered storage moves older data from local broker disks to object storage, which makes long-term retention cheaper and limits rebalancing to the local hot set. This lets data scientists replay historical events directly from Kafka for analysis or model training. In a connected-car example, Kafka receives sensor data, stream processing prepares it, TensorFlow trains a model, and a Kafka application performs real-time scoring. Kai argues that embedding scoring in the Kafka application can avoid the latency and failure-handling problems of a separate HTTP model server for high-volume use cases. He also describes Kafka-based monitoring, reproducibility through immutable event logs, and changing model weights through Kafka topics. He is clear that Kafka does not replace every database or batch engine.
Kafka decouples producers, consumers, and retention
Kai describes Kafka as messaging, storage, and a back-pressure system. Producers can keep writing even when consumers are offline or falling behind. Each topic can have its own retention period, such as two hours for logs or up to ten years for customer transactions. Because events remain ordered and timestamped, a consumer can later reprocess a selected period or replay data for analytics and model training. Kafka Connect links the event stream to legacy databases and mainframes, as well as systems such as HDFS, S3, MongoDB, and MQTT. Kafka Streams and KSQLDB provide processing on top of the stored events.
Kafka can replace a separate database for some event workloads
Kafka stores append-only events in guaranteed order, with timestamps that let consumers select a particular month or another slice of the log. Kai says this can be enough for some use cases, but Kafka does not provide native ANSI SQL and does not replace Oracle, Elasticsearch, or MongoDB for their specific workloads. A common pattern is to use Kafka as the central event system and build materialized views in MongoDB, S3, or a time-series database. Each downstream system consumes the events it needs and stores its own view.
Kafka reduces a railway information system's collection of components
Kai uses Deutsche Bahn as an example of why Kafka is different from a messaging queue. The railway needed real-time information, but station displays could only receive CSV files every ten minutes, while legacy systems also required database integration and processing. A RabbitMQ-based design grew to include storage, caching, processing, and integration frameworks. Deutsche Bahn re-engineered the system with Kafka, which provided messaging, storage, data integration, and processing in one distributed framework. The example was being rolled out across German stations at the time of the talk.
Tiered storage makes long-term Kafka retention practical
Kafka brokers normally use attached disks for both processing and storage. That works when data expires after hours or days, but large retained datasets make disks expensive and make recovery slow when a broker fails or is replaced. With tiered storage, brokers keep a local hot set while older data moves to an object store such as Amazon S3 or Google Cloud Storage. Applications continue using the same Kafka API. Teams can choose how long each topic stays local before being offloaded. Kai says customers were already storing petabytes through tiered storage, and that rebalancing then affects only the local hot set rather than the full retained dataset.
Kafka can feed machine learning directly from the event stream
In the connected-car example, cars send sensor data through MQTT into Kafka. Stream processing performs filtering, aggregation, and other preparation, while a Python application uses the Kafka and TensorFlow libraries to consume events and train a model. Training remains batch in most cases, although online training methods such as online clustering can work in real time. The trained model is placed in cloud object storage. A separate Kafka Streams application loads the model and scores events in real time, with Kafka providing ordering, availability, and delivery guarantees.
Embedding scoring in Kafka trades model-server features for event-level performance
Kai compares embedding a model in a Kafka application with calling a model server over HTTP. Model servers offer features such as versioning and parameter changes out of the box. An embedded model can be a better fit when connected cars produce very high event volumes, low latency matters, or connectivity can be intermittent. Customers can send new model metadata or weights through a Kafka topic, allowing the scoring application to update without downtime. Regulated environments may require parallel versions and A/B testing so teams can prove which model handled each event.
The Kafka event log supports replay, monitoring, and explanation
Because Kafka events are appended to a log and are not changed afterward, teams can replay the same input for different models and compare their outputs. Kai also describes using Kafka topics for monitoring. Technical metrics such as uptime and latency can flow to Prometheus and Grafana, while other consumers can write to TimescaleDB or InfluxDB. Business metrics, including model accuracy, require different monitoring choices. The same stored event history can support regulatory reporting and help explain what happened in a transaction or model workflow.
Kafka complements batch engines and other infrastructure
Kai says Kafka processes messages in batches internally for performance, even when the application appears real time. It is not designed for large MapReduce-style batch jobs with shuffling, where Spark remains a better consumer. Kafka also complements systems such as MongoDB, rather than replacing them in every case. He describes uses ranging from mainframe integration and industrial IoT to transactional systems for orders, fraud detection, payments, and trading. In these workloads, zero downtime, zero data loss, and exactly-once semantics can matter more than very large data volumes.
"Kafka provides all of this in one single component because again Kafka is messaging its storage, its data integration and its data processing, all of that in one framework at scale in real time."Kai Waehner13:44
Who should watch
You are deciding whether Kafka should be only an ingestion layer or the central event system for real-time applications.
Your machine learning pipeline needs replayable historical events, direct stream consumption, or high-volume online scoring.
You are evaluating tiered storage and want to understand its effect on Kafka cost, retention, and broker recovery.
