Message Queue
Ein strukturelles Integrationsmuster zur asynchronen Übertragung von Nachrichten zwischen Systemkomponenten.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Fehlende Backpressure-Steuerung kann zu Ressourcenauslastung führen.
- Inkonsistente Nachrichtenverarbeitung bei fehlender Idempotenz.
- Datenverlust bei falscher Persistenz- oder Replikationskonfiguration.
- Idempotente Konsumenten implementieren.
- SLA-orientiertes Monitoring von Queue-Länge und Latenz einrichten.
- Dead-Letter-Queues und klare Fehlerprozesse definieren.
I/O & Ressourcen
- Produzierende Anwendungen oder Dienste
- Nachrichtenformat- und Schema-Definitionen
- Konfigurierter Messaging-Broker und Netzwerkzugang
- Zuverlässig zugestellte Nachrichten an Konsumenten
- Metriken zu Durchsatz, Latenz und Fehlern
- Dead-Letter- und Fehlerprotokolle für Nachbearbeitung
Beschreibung
Eine Message Queue ist ein strukturelles Integrationsmuster, das asynchrone Kommunikation zwischen Systemkomponenten ermöglicht, indem Nachrichten temporär gespeichert und zuverlässig zugestellt werden. Sie entkoppelt Sender und Empfänger, unterstützt Lastverteilung, Fehlerisolierung und Wiederholungsmechanismen. Architekturelle Entscheidungen betreffen Persistenz, Durchsatz, Latenz und Konsistenz.
✔Vorteile
- Verbesserte Skalierbarkeit durch asynchrone Pufferung.
- Erhöhte Fehlertoleranz durch Entkopplung und Retries.
- Glättung von Lastspitzen ohne direkte Belastung der Konsumenten.
✖Limitationen
- Zusätzliche Komplexität in Betrieb und Monitoring.
- Mögliche erhöhte End-to-End-Latenz durch asynchrone Verarbeitung.
- Erfordert klare Konventionen für Nachrichtenformate und Fehlerbehandlung.
Trade-offs
Metriken
- Durchsatz (Nachrichten/s)
Anzahl der erfolgreich übertragenen Nachrichten pro Sekunde.
- Warteschlangenlänge
Aktuelle Anzahl nicht verarbeiteter Nachrichten in der Queue.
- Zeit bis zur Zustellung (End-to-End-Latenz)
Durchschnittliche Zeit von Erzeugung bis erfolgreicher Verarbeitung einer Nachricht.
Beispiele & Implementierungen
RabbitMQ für robuste Work-Verarbeitung
RabbitMQ als Broker zur zuverlässigen Zustellung und Dead-Letter-Verarbeitung in einem Microservices-System.
Amazon SQS für elastische Queueing-Modelle
SQS als vollständig verwalteter Service zum Puffern von Spitzenlasten und zur einfachen Skalierung.
Kafka für hohe Durchsatz-Event-Streams
Apache Kafka wird als verteiltes Log genutzt, wenn Reihenfolge, hoher Durchsatz und Replikation zentral sind.
Implementierungsschritte
Anforderungen und Durchsatz-/Latenzziele definieren.
Broker-Typ (z. B. AMQP, Kafka, SQS) auswählen und prototypisch testen.
Nachrichtenformate, Retry- und Dead-Letter-Strategien festlegen und integrieren.
⚠️ Technische Schulden & Engpässe
Tech Debt
- Monolithische Queue-Konfiguration ohne Partitionierung oder Priorisierung.
- Fehlendes Schema-Registry führt zu inkonsistenten Nachrichtenformaten.
- Unzureichende Replikation und Backup-Strategien für Persistenz.
Bekannte Engpässe
Beispiele für Missbrauch
- Verwendung einer Queue als primäre Datenbank ohne Replikationsgarantien.
- Persistente Speicherung aller Nachrichten ohne Aufbewahrungsstrategie.
- Fehlende Idempotenz führt zu doppelter Verarbeitung von Bestellungen.
Typische Fallen
- Unterschätzung der Operationalisierung (Backup, Monitoring, Scaling).
- Falsche Annahmen über Nachrichtenreihenfolge in verteilten Setups.
- Nicht getestete Failure-Szenarien für Broker-Partitionen.
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Begrenzte Durchsatzkapazität des gewählten Brokers.
- • Compliance-Anforderungen an Datenhaltung und Verschlüsselung.
- • Netzwerk-Latenz zwischen Produzenten, Broker und Konsumenten.