Streaming
Architekturparadigma zur kontinuierlichen Verarbeitung und Übertragung von Datenströmen in Echtzeit zur Unterstützung niedriger Latenz und entkoppelter Integrationen.
Klassifikation
- KomplexitätHoch
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Dateninkonsistenzen bei fehlerhaften Retry-Strategien.
- Kostensteigerung durch dauerhafte Infrastruktur und Speicherbedarf.
- Operationaler Overhead bei Schemata und Backups.
- Ereignisevolution mit abwärtskompatiblen Schemata planen.
- Idempotente Konsumenten und klare Retry-Strategien einsetzen.
- Metriken für Latenz, Durchsatz und Consumer-Lag kontinuierlich messen.
I/O & Ressourcen
- Ereigniserzeuger (Microservices, Geräte, externe Systeme)
- Schema-Registry oder Datenmodell
- Streaming-Plattform (Broker, Connectors, Stream-Processor)
- Kontinuierliche Ereignisströme für Konsumenten
- Echtzeit-Aggregationen und Metriken
- Persistente Ereignisspeicherung für Auditing und Replays
Beschreibung
Streaming beschreibt die kontinuierliche Verarbeitung und Übertragung von Ereignissen oder Datenströmen in Echtzeit. Es ermöglicht niedrige Latenz, stetige Auswertung und entkoppelte Integration zwischen Produzenten und Konsumenten und unterstützt Skalierung, Fehlertoleranz sowie Zustandsspeicherung. Effektiver Einsatz erfordert Architekturentscheidungen, geeignete Betriebsprozesse und Observability.
✔Vorteile
- Niedrige Latenz für Echtzeit-Entscheidungen.
- Bessere Skalierbarkeit durch asynchrone Entkopplung.
- Flexiblere Integration heterogener Systeme.
✖Limitationen
- Erhöhter Betriebsaufwand für Zustandsverwaltung und Replikation.
- Komplexere Fehleranalyse und Wiederherstellungsszenarien.
- Nicht immer nötig für einfache, latenztolerante Batch-Workloads.
Trade-offs
Metriken
- End-to-End-Latenz
Zeit zwischen Produktion eines Events und dessen Verarbeitung durch Verbraucher.
- Durchsatz (Events/s)
Anzahl der verarbeiteten Ereignisse pro Sekunde.
- Consumer-Lag
Verzögerung oder Rückstand zwischen Produzent und Konsument.
Beispiele & Implementierungen
LinkedIn und Apache Kafka
LinkedIn entwickelte Kafka zur zuverlässigen Verteilung von Ereignisströmen über Dienste hinweg.
Netflix Echtzeit-Streaming
Netflix nutzt Streaming-Pipelines für Monitoring, Personalisierung und Betreibbarkeit in Echtzeit.
IoT-Telemetrie in der Industrie
Fabriken streamen Sensordaten zur kontinuierlichen Analyse und vorausschauenden Wartung.
Implementierungsschritte
Bedarfsanalyse und Latenz-/Durchsatz-Anforderungen definieren.
Ereignisschemata und Versionierungsregeln etablieren.
Streaming-Plattform auswählen und Proof-of-Concept implementieren.
Stateful Processing und Fault-Tolerance testen und monitoren.
Betriebshandbuch, Runbooks und Observability aufbauen.
⚠️ Technische Schulden & Engpässe
Tech Debt
- Ad-hoc-Topic-Strukturen statt klarer Namenskonventionen.
- Unzureichende Archivierung alter Events und Wachstum des Speichers.
- Fehlende automatisierte Tests für Event-Processing-Pipelines.
Bekannte Engpässe
Beispiele für Missbrauch
- Echtzeit-SLA erreichen wollen, obwohl Batch-Lösungen ausreichend wären.
- Direktes Schreiben von Produzenten in Konsumentendatenbanken ohne Events.
- Unkontrollierte Topic-Erstellung ohne Governance und Kostenabschätzung.
Typische Fallen
- Unterschätzen der Komplexität von zustandsbehafteten Operatoren.
- Fehlende Backpressure-Mechanismen bei hohen Lastspitzen.
- Nicht berücksichtigte Schema-Inkompatibilitäten zwischen Teams.
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Begrenzter Speicher für zustandsbehaftete Operatoren
- • Netzwerkbandbreite zwischen Rechenzonen
- • Kompatibilitätsanforderungen für Ereignisschemata