Apache Kafka — Event Streaming für Microservices

RabbitMQ dient uns gut für Task Queues. Aber für Event-driven Architektur — wo jeder Interessent ein Event erhalten und es erneut abspielen können soll — braucht man ein anderes Modell. Apache Kafka ist ein verteiltes Commit Log, keine Message Queue.

Kafka vs. RabbitMQ¶

RabbitMQ: Eine Nachricht wird an einen Consumer zugestellt und gelöscht. Kafka: Eine Nachricht wird ins Log geschrieben und gespeichert (Tage, Wochen). Jeder Consumer liest unabhängig aus dem Log. Replay ist möglich.

Konzepte¶

Topics: Logische Kanäle (order-events, user-events). Partitions: Horizontale Skalierung — ein Topic wird in Partitions aufgeteilt. Consumer Groups: Consumer in einer Gruppe teilen sich die Partitions. Offsets: Jeder Consumer merkt sich, wo er im Log aufgehört hat.

// Producer
Properties props = new Properties();
props.put("bootstrap.servers", "kafka:9092");
props.put("key.serializer", StringSerializer.class);
props.put("value.serializer", StringSerializer.class);

Producer<String, String> producer = new KafkaProducer<>(props);
producer.send(new ProducerRecord<>("order-events", orderId, orderJson));

Use Cases¶

• Event Sourcing — Events statt Zustand speichern
• Data Pipeline — Daten zwischen Systemen streamen
• Log Aggregation — zentrales Sammeln von Logs
• Stream Processing — Echtzeit-Datentransformation

Betriebserfahrungen¶

Kafka erfordert ZooKeeper zur Koordination. Ein Cluster mit 3 Brokern und Replication Factor 3 ist das Minimum für die Produktion. Operativ anspruchsvoller als RabbitMQ, aber der Durchsatz ist um Größenordnungen höher.

Kafka für Events, RabbitMQ für Tasks¶

Kafka ist kein Ersatz für RabbitMQ — es ist ein anderes Werkzeug für ein anderes Problem. Event-driven Architektur mit Kafka, Task Queues mit RabbitMQ. Beides in unserem Stack.