Warum Message Broker?

In modernen Microservice-Architekturen müssen Dienste miteinander kommunizieren, ohne direkt voneinander abhängig zu sein. Message Broker entkoppeln Produzenten und Konsumenten: Der Sender schickt eine Nachricht in eine Queue oder ein Topic, der Empfänger holt sie ab – asynchron und unabhängig voneinander. Das erhöht Skalierbarkeit, Fehlertoleranz und Wartbarkeit erheblich.

Die drei meistgenutzten Open-Source-Message-Broker im Jahr 2026 sind Apache Kafka, RabbitMQ und NATS. Jeder verfolgt einen anderen Ansatz – und die Wahl entscheidet maßgeblich über Architektur und Betriebsaufwand.

Apache Kafka: Event-Streaming für massive Datenmengen

Kafka wurde ursprünglich bei LinkedIn entwickelt und ist heute Teil der Apache Software Foundation. Kafka ist kein klassischer Message Broker, sondern eine verteilte Event-Streaming-Plattform: Nachrichten werden in Topics geschrieben und in partitionierten, replizierten Logs gespeichert. Das macht Kafka einzigartig – Events bleiben erhalten und können beliebig oft neu gelesen werden.

Stärken von Kafka:

  • Hoher Durchsatz: Millionen von Events pro Sekunde sind möglich – Kafka ist für Big-Data-Pipelines ausgelegt
  • Langfristige Datenhaltung: Events bleiben konfigurierbar lang gespeichert (Tage, Wochen, dauerhaft) und können wiederholt gelesen werden
  • Consumer Groups: Mehrere Konsumenten können denselben Stream parallel lesen, ohne sich gegenseitig zu beeinflussen
  • Kafka Streams: Integrierte Stream-Processing-Bibliothek für Echtzeit-Transformationen direkt im Broker
  • Kafka Connect: Framework zum Import/Export aus Datenbanken, S3, Elasticsearch und weiteren Systemen
  • KRaft-Modus: Seit Kafka 3.3 ohne ZooKeeper-Abhängigkeit – vereinfachtes Deployment

Schwächen von Kafka:

  • Komplexer Betrieb: Mehrere Broker-Knoten für High Availability, sorgfältiges Tuning notwendig
  • Overhead bei kleinen Teams: Für weniger als 10.000 Messages pro Sekunde ist Kafka oft Overkill
  • Latenz: Kafka ist für Durchsatz optimiert, nicht für ultralow Latency

Kafka ist die richtige Wahl, wenn du Event Sourcing, Data Pipelines, Audit Logs oder Stream Processing im großen Stil betreibst.

RabbitMQ: Der klassische Message Broker

RabbitMQ implementiert das AMQP-Protokoll (Advanced Message Queuing Protocol) und bietet das traditionellste Message-Broker-Modell: Exchanges leiten Nachrichten anhand von Routing Keys an Queues weiter. Diese klassische Architektur ist extrem flexibel – du kannst Fan-out, Direct, Topic und Header Exchanges kombinieren.

Stärken von RabbitMQ:

  • Protokollunterstützung: AMQP, MQTT, STOMP und HTTPS-Plugins out of the box
  • Flexible Routing-Logik: Exchanges und Bindings ermöglichen komplexe Routing-Szenarien ohne Code-Änderungen
  • Management UI: Übersichtliche Web-Oberfläche zum Monitoring von Queues, Connections und Messages in Echtzeit
  • Acknowledgments und Dead-Letter-Queues: Robuste Fehlerbehandlung – unbearbeitete Nachrichten landen automatisch in DLQs
  • Niedriger Ressourcenverbrauch: Läuft problemlos auf kleineren Maschinen und Docker-Setups
  • Shovel und Federation: Eingebaute Mechanismen zum Replizieren von Nachrichten zwischen RabbitMQ-Instanzen

Schwächen von RabbitMQ:

  • Nachrichten sind flüchtig: RabbitMQ ist nicht für langfristige Message-Retention ausgelegt – nach dem Lesen sind Nachrichten weg
  • Kein Event-Streaming: Keine Kafka-ähnliche Replay-Funktion für persistente Streams
  • Skalierung ist komplex: Bei sehr hohem Durchsatz muss ein Cluster aufgebaut werden

RabbitMQ ist ideal für klassische Task-Queues, RPC-Muster, Workflow-Orchestrierung und überall, wo flexible Routing-Logik gefragt ist.

NATS: Hochperformant und ultra-einfach

NATS ist der modernste unter den dreien – und der mit dem simpelsten Design. NATS verfolgt das Prinzip "Everything is a message": Publish/Subscribe, Request/Reply und Queue Groups decken 90% aller Use Cases ab, mit minimalem Overhead und maximaler Performance.

Stärken von NATS:

  • Extrem geringe Latenz: NATS ist für Sub-Millisekunden-Latenz optimiert – ideal für Edge-Computing und IoT
  • Einfaches Deployment: Ein einzelnes Binary, keine externen Abhängigkeiten
  • JetStream: Persistenz-Schicht über NATS Core – Kafka-ähnliches Streaming, aber deutlich einfacher zu betreiben
  • Automatisches Clustering: NATS-Server clustern mit wenigen Konfigurationszeilen
  • Kubernetes-native: NATS Operator und Helm Chart sind gut maintained
  • Security: TLS, Accounts und Decentralized Authorization (NKEYS/JWT) standardmäßig

Schwächen von NATS:

  • Kleineres Ökosystem: Weniger Client-Libraries und fertige Integrationen als Kafka oder RabbitMQ
  • JetStream ist jünger: Solider als früher, aber in Hyperscale-Setups weniger erprobt als Kafka Streams
  • Monitoring: Weniger umfangreich als RabbitMQs Management UI

NATS eignet sich besonders für Microservices mit niedriger Latenz, IoT-Systeme, Edge Computing und Teams, die Betriebssimplizität priorisieren.

Direkter Vergleich

Kriterium Kafka RabbitMQ NATS
Durchsatz Sehr hoch (Millionen/s) Hoch (10K–100K/s) Sehr hoch (Millionen/s)
Latenz Mittel (ms-Bereich) Niedrig (µs–ms) Sehr niedrig (µs)
Message Retention Tage/Wochen/dauerhaft Bis zur Zustellung Optional (JetStream)
Protokolle Kafka-Protokoll AMQP, MQTT, STOMP NATS-Protokoll
Betriebsaufwand Hoch Mittel Niedrig
Streaming Nativ Nein JetStream
Routing-Flexibilität Mittel Sehr hoch Mittel
Deployment-Komplexität Hoch Mittel Niedrig

Self-Hosting: Aufwand im Vergleich

Alle drei lassen sich in Kubernetes mit Helm deployen:

  • Kafka: bitnami/kafka oder Strimzi Operator – mehrere Pods, Persistent Volumes für High Availability notwendig. Strimzi abstrahiert Kafka-Cluster als Custom Resources, was den Betrieb deutlich vereinfacht.
  • RabbitMQ: bitnami/rabbitmq – auch als Single-Node möglich, Cluster für HA. Das RabbitMQ Cluster Operator für Kubernetes ist offiziell unterstützt und well-documented.
  • NATS: nats/nats – leichtgewichtigster Helm Chart der drei, auch StatefulSet optional. NATS Leaf Nodes ermöglichen globale Verbindungen ohne VPN.

Für ein kleines Self-Hosted-Setup (Homelab oder kleines Startup) empfiehlt sich RabbitMQ als erstes: Die Management UI schafft schnell Transparenz und AMQP ist ein bewährtes Protokoll. Für IoT-Projekte oder wenn du Kubernetes bereits nutzt, ist NATS mit JetStream der modernere Einstieg.

Wann welchen Broker wählen?

Kafka wählen wenn:

  • Du Log-Aggregation, Data Pipelines oder Event Sourcing betreibst
  • Du Millionen von Events pro Sekunde verarbeiten musst
  • Replay-Funktionalität eine Kernanforderung ist
  • Du Stream Processing direkt im Broker ausführen willst

RabbitMQ wählen wenn:

  • Du komplexe Routing-Logik benötigst
  • MQTT für IoT-Geräte gefragt ist
  • Task-Queue-Pattern dein Hauptmuster ist
  • Du mehrere Protokolle aus einem System bedienen musst

NATS wählen wenn:

  • Ultra-niedrige Latenz entscheidend ist
  • Betriebseinfachheit oberste Priorität hat
  • Du Microservices mit Request/Reply verbindest
  • Edge- oder IoT-Szenarien im Fokus stehen

Fazit

Kafka, RabbitMQ und NATS lösen ähnliche Probleme auf unterschiedliche Weisen. Kafka dominiert im Enterprise-Streaming-Bereich mit unübertroffener Retention und Replay-Funktion. RabbitMQ ist der Allrounder für klassische Messaging-Szenarien mit flexiblem Routing. NATS überzeugt mit Einfachheit und Latenz. Die Entscheidung hängt von Durchsatz, Retention-Anforderungen, Betriebsressourcen und der Komplexität deiner Routing-Logik ab.

Weiterführende Artikel

Verwandte Technologien im Techradar