Moderne Cloud-Anwendungen bestehen oft aus vielen kleinen Komponenten, die asynchron miteinander kommunizieren. Statt ständiger direkter Aufrufe („Service A ruft Service B auf“) setzen sie auf Messaging und Event-basiertes Design. Das bringt mehr Flexibilität, Skalierbarkeit und Fehlertoleranz – vor allem in Microservice-Architekturen.
In diesem Teil lernst du:
- Was Messaging- und Event-basierte Systeme sind
- Welche Cloud-Dienste dafür existieren
- Wie du Queues, Topics & Events sinnvoll einsetzt
- Und worauf du beim Design achten solltest
Was ist Messaging in der Cloud?
Messaging beschreibt den asynchronen Datenaustausch zwischen zwei oder mehr Systemen über Nachrichten. Eine Nachricht (Message) enthält dabei z. B.:
- ein Event (z. B. „Benutzer hat gekauft“)
- oder einen Auftrag (z. B. „Rechnung erstellen“)
Warum Messaging?
- Dienste müssen nicht gleichzeitig online sein
- Entkopplung von Sender & Empfänger
- Bessere Fehlertoleranz & Resilienz
- Ideal für Lastspitzen, Warteschlangen, Hintergrundprozesse
Messaging vs. Events – Wo ist der Unterschied?
| Aspekt | Messaging | Eventing |
|---|---|---|
| Ziel | Zielgerichtete Kommunikation („Auftrag“) | Systemweiter Hinweis („etwas ist passiert“) |
| Typisch genutzt für | Auftragsverarbeitung | Trigger von Aktionen |
| Empfänger | 1:1 (Consumer) | 1:n (Subscriber) |
| Zustellung | Sicher, oft FIFO | Oft „at most once“, aber schnell |
Beispiel Messaging:
Eine Bestellung wird in eine Warteschlange gelegt → ein Service verarbeitet sie
Beispiel Eventing:
Ein neues Nutzerkonto wird erstellt → mehrere Systeme (E-Mail, CRM, Analytics) reagieren darauf
Messaging in der Cloud: Die wichtigsten Dienste
| Cloud-Anbieter | Queue/Topic-Dienst | Besonderheiten |
|---|---|---|
| AWS | SQS (Simple Queue Service) | Klassische Queues, einfach & robust |
| SNS (Simple Notification Service) | Topic-basiert, Fan-out zu mehreren Zielen | |
| Azure | Service Bus | Advanced Features, Ordered Delivery, DLQ |
| Event Grid | Ereignisrouting, Serverless, Event Hubs | |
| GCP | Pub/Sub | High Throughput, global verteilt, skalierbar |
AWS SQS & SNS
- SQS: Warteschlangen (FIFO oder Standard), geeignet für Job-Queues
- SNS: Topics mit verschiedenen Abonnenten (HTTP, Lambda, SQS, E-Mail)
- Pattern: SNS → SQS → Lambda (Fan-out mit Queue-Puffer)
Beispiel:
Ein Bestell-Service veröffentlicht Event an SNS → Rechnung, Versand, Lagerhaltung hören mit
Azure Service Bus & Event Grid
- Service Bus: Queue- und Topic-Mechanismus mit Sessions, Retry-Handling, DLQs (Dead Letter Queues)
- Event Grid: Cloud-eigenes Eventing-System, reagiert auf Events aus Azure-Diensten (z. B. Blob Upload)
Beispiel:
Upload in Blob Storage löst Event in Event Grid aus → Azure Function verarbeitet Datei
Google Pub/Sub
- Hochperformanter, verteilter Messaging-Dienst
- Topics + Subscriptions
- Unterstützt Pull & Push Delivery, mit „at least once“-Zustellung
- Gute Integration mit Cloud Functions, Dataflow, BigQuery
Beispiel:
IoT-Geräte senden Daten → Pub/Sub verteilt Events an mehrere GCP-Dienste
Nachrichtentypen & Kommunikationsmuster
Point-to-Point (Queue)
- Ein Producer → Eine Queue → Ein Consumer
- Beispiel: Job-Queue für Rechnungsservice
Publish/Subscribe (Topic)
- Ein Producer → Ein Topic → Viele Subscriber
- Beispiel: Ein Event „User erstellt“ triggert mehrere Systeme
Request-Reply (RPC)
- Client schickt Nachricht und erwartet Antwort
- Weniger geeignet für asynchrone Systeme – erfordert zusätzliches Management
Event-basierte Architekturen: Vorteile
| Vorteil | Beschreibung |
|---|---|
| Entkopplung | Sender kennt Empfänger nicht – mehr Flexibilität |
| Skalierbarkeit | Messages können gepuffert werden |
| Fehlertoleranz | Keine harte Abhängigkeit – z. B. Retry, DLQ |
| Erweiterbarkeit | Weitere Empfänger können einfach hinzugefügt werden |
| Auditing | Events können geloggt & ausgewertet werden |
Herausforderungen
| Problem | Beschreibung |
|---|---|
| Komplexe Fehlerbehandlung | Retry, DLQ, Duplicate Handling |
| Tracing / Debugging | Wer hat wann was verarbeitet? |
| Schema-Management | Payload muss versionsstabil bleiben |
| Nicht geeignet für alles | Echtzeit-Systeme brauchen oft andere Patterns |
Tools & Standards
| Tool / Technik | Beschreibung |
|---|---|
| Apache Kafka | Hochperformantes Event-Streaming-System |
| CloudEvents | Standardformat für Event Payloads |
| Schema Registry | Versionskontrolle für Event-Formate |
| OpenTelemetry | Tracing & Observability für Event-Flows |
Best Practices für Messaging & Eventing
- Nie auf „Fire & Forget“ verlassen – immer Error-Handling einbauen
- Payloads versionieren – z. B. durch
"type": "UserCreatedV2" - Idempotenz sicherstellen – d. h. eine Nachricht kann doppelt verarbeitet werden, ohne Schaden
- Monitoring & Dead Letter Queues aktivieren
- Services voneinander trennen – keine direkten Rückkanäle, sonst verlierst du die Entkopplung
Fazit
Messaging und Event-basierte Architekturen gehören zur DNA moderner Cloud-Anwendungen. Sie ermöglichen lose Kopplung, flexible Erweiterung und bessere Skalierbarkeit – gerade in Microservice-Umgebungen oder bei stark asynchronen Prozessen.
Schreibe einen Kommentar