Message Queue
Ein Kommunikationsmuster, bei dem Nachrichten in einer Warteschlange zwischengespeichert werden – ermöglicht asynchrone, entkoppelte Kommunikation zwischen Services.
Ein Architekturmuster, bei dem Komponenten über Ereignisse (Events) kommunizieren statt direkt miteinander – für lose Kopplung, Skalierbarkeit und Reaktionsfähigkeit.
In traditionellen Architekturen ruft Service A direkt Service B auf: „Verarbeite diese Bestellung.” Service A wartet, bis B antwortet. Das ist einfach, aber problematisch: Wenn B langsam ist, ist A langsam. Wenn B ausfällt, fällt A aus.
Event-Driven Architecture dreht das um: Service A sendet ein Event – „Bestellung aufgegeben” – und macht sofort weiter. Service B, C und D hören auf dieses Event und reagieren unabhängig voneinander. A weiß nicht einmal, dass B, C und D existieren.
Synchron vs. Asynchron:
| Aspekt | Request-Response | Event-Driven |
|---|---|---|
| Kopplung | Eng (A kennt B) | Lose (A kennt nur Event) |
| Timing | Synchron (warten) | Asynchron (fire & forget) |
| Skalierung | Gemeinsam | Unabhängig pro Consumer |
| Debugging | Einfach | Komplex (verteilt) |
{
"eventId": "evt_01HX...",
"eventType": "document.uploaded",
"timestamp": "2026-02-19T18:00:00Z",
"source": "upload-service",
"data": {
"documentId": "doc_123",
"userId": "usr_456",
"filename": "report.pdf",
"sizeBytes": 204800
}
}
Upload Service → [document.uploaded] → Chunking Service
→ Virus Scanner
→ Audit Logger
Chunking Service → [document.chunked] → Embedding Service
Embedding Service → [embeddings.created] → Vector DB Service
→ Search Index Service
from kafka import KafkaProducer, KafkaConsumer
import json
# Producer: Event senden
producer = KafkaProducer(bootstrap_servers='kafka:9092')
producer.send('document.uploaded', json.dumps({
"documentId": "doc_123",
"filename": "report.pdf"
}).encode())
# Consumer: Event verarbeiten
consumer = KafkaConsumer('document.uploaded', bootstrap_servers='kafka:9092')
for message in consumer:
event = json.loads(message.value)
chunk_document(event['documentId']) Event-Driven Architecture ist wie ein Nachrichtensystem in einer Redaktion: Ein Reporter schreibt einen Artikel (Event) und legt ihn in den Posteingang. Alle Abteilungen, die sich dafür interessieren (Druck, Online, Social Media), holen ihn sich selbst ab. Der Reporter muss nicht wissen, wer den Artikel verwendet.
Producer sendet Events, Consumer reagieren darauf – ohne direkte Verbindung
Lose Kopplung: Producer weiß nicht, wer seine Events konsumiert
Asynchron: Producer wartet nicht auf Antwort des Consumers
KI-Pipeline-Orchestrierung
Neues Dokument hochgeladen → Event → Chunking → Embedding → Vektordatenbank – jeder Schritt unabhängig skalierbar
Echtzeit-Benachrichtigungen
Bestellung aufgegeben → Events an Lager, Zahlung, E-Mail-Service – alle parallel, ohne Abhängigkeiten
Audit Logs
Jede Aktion erzeugt ein Event – unveränderlicher Verlauf aller Systemereignisse
Request-Response (REST): Service A ruft Service B auf und wartet auf Antwort – synchron, direkte Kopplung. Event-Driven: Service A sendet ein Event und macht weiter – asynchron, lose Kopplung. Service B reagiert, wenn es bereit ist. EDA ist besser für Skalierung, aber schwieriger zu debuggen.
Ein Event beschreibt etwas, das passiert ist: 'Bestellung aufgegeben' (Vergangenheit, unveränderlich). Eine Message ist eine Anweisung: 'Verarbeite diese Bestellung' (Gegenwart, Aufforderung). Events sind oft unveränderlich und können von mehreren Consumern gelesen werden.
Ein Muster, bei dem der Zustand eines Systems nicht als aktueller Snapshot gespeichert wird, sondern als Folge aller Events, die zu diesem Zustand geführt haben. Der aktuelle Zustand wird durch Replay aller Events rekonstruiert. Vollständige Auditierbarkeit, aber höhere Komplexität.