Real-time Streaming mit Apache Kafka und Flink: Architektur für 2026¶

Echtzeit-Datenverarbeitung ist kein Luxus mehr. Im Jahr 2026 ist es eine grundlegende Anforderung für Betrugserkennung, Handelssysteme, IoT-Telemetrie und Personalisierung der Kundenerfahrung. Apache Kafka und Apache Flink bilden das Rückgrat der meisten produktiven Streaming-Architekturen.

Warum Kafka + Flink?¶

Kafka fungiert als verteiltes Commit Log — ein zuverlässiger, skalierbarer Event Store mit Ordnungsgarantien. Flink ist ein Stateful Stream Processor mit Exactly-once-Semantik und Sub-Sekunden-Latenz.

Gemeinsam decken sie die gesamte Pipeline ab:

• Ingest -> Kafka (Producer, Konnektoren, CDC)
• Process -> Flink (Transformationen, Aggregationen, Windowing, Pattern Detection)
• Serve -> Kafka -> Consumer (Datenbanken, APIs, Dashboards, Alerting)

Referenzarchitektur¶

┌─────────────┐    ┌─────────────┐    ┌──────────────┐    ┌────────────┐
│  Producers  │───▶│    Kafka     │───▶│    Flink      │───▶│  Sink/DB   │
│  (API, IoT, │    │  (Topics,   │    │  (Jobs,       │    │  (Postgres,│
│   CDC, App) │    │   Partitions)│    │   Windows,    │    │   Redis,   │
└─────────────┘    └─────────────┘    │   State)      │    │   S3, API) │
                                       └──────────────┘    └────────────┘

Kafka Cluster — Best Practices 2026¶

Sizing: - Mindestens 3 Broker für Produktion (5+ für High-Throughput) - KRaft-Modus (ohne ZooKeeper) — seit Kafka 3.5+ produktionsreif - Tiered Storage für kosteneffiziente Retention (Hot/Warm/Cold)

Topic-Design: - Partition Count = erwarteter Durchsatz / Partition-Durchsatz (~10 MB/s pro Partition) - Replication Factor 3 (min.insync.replicas=2) - Compacted Topics für State/Lookup-Daten - Namenskonvention: {domain}.{entity}.{version} (z.B. trading.orders.v2)

Schema Management: - Confluent Schema Registry (Avro/Protobuf) - Schema-Evolution = backward + forward compatible - Niemals den Feldtyp ändern, nur optionale Felder hinzufügen

Flink Jobs — Production Patterns¶

Windowing-Strategien:

// Tumbling window — fixed intervals (e.g., 1-minute aggregations)
stream
    .keyBy(event -> event.getSymbol())
    .window(TumblingEventTimeWindows.of(Time.minutes(1)))
    .aggregate(new VWAPAggregator());

// Sliding window — overlapping windows (5 min window, 1 min slide)
stream
    .keyBy(event -> event.getSymbol())
    .window(SlidingEventTimeWindows.of(Time.minutes(5), Time.minutes(1)))
    .process(new MovingAverageFunction());

// Session window — dynamic windows based on activity
stream
    .keyBy(event -> event.getUserId())
    .window(EventTimeSessionWindows.withGap(Time.minutes(30)))
    .process(new SessionAnalyzer());

Watermarks und verspätete Daten: - Watermark = Fortschrittsindikator für Event Time - BoundedOutOfOrdernessWatermarks mit einer Toleranz von 5–30 Sekunden - Verspätete Daten -> Side Output für spätere Verarbeitung - Niemals auf Processing Time für Geschäftslogik vertrauen

State Management: - RocksDB State Backend für großen State (TB+) - Inkrementelles Checkpointing (Intervall 1–5 Minuten) - State TTL für automatisches Cleanup alter Schlüssel - Savepoints vor jedem Deployment

Enterprise-Anwendungsfälle¶

1. Betrugserkennung (< 100ms Latenz)¶

Flink CEP (Complex Event Processing) ermöglicht die deklarative Definition von Betrugsmustern direkt im Code. Reale Systeme kombinieren regelbasiertes CEP mit einem ML-Modell (Feature Store befüllt durch Flink, Echtzeit-Inferenz).

2. Trading und Marktdaten¶

VWAP-Berechnung, Order-Book-Rekonstruktion, Spread-Monitoring, Regime-Erkennung und Signalgenerierung — alles in Echtzeit mit Sub-10ms-Latenz.

3. IoT-Telemetrie und vorausschauende Wartung¶

Tausende Sensoren -> Kafka (MQTT-Bridge) -> Flink: Anomalieerkennung, Rolling Statistics, prädiktive Modelle und Alert-Eskalation.

4. Echtzeit-Personalisierung¶

E-Commerce-/Content-Plattformen: User-Clickstream -> Kafka -> Flink -> Feature-Update, Session-Level-Features und Echtzeit-Recommendation-Model-Updates.

Monitoring und Observability¶

Stack: Prometheus + Grafana + Custom Dashboards. Kafka Exporter für JMX-Metriken, Flink hat einen nativen Prometheus Reporter.

Deployment und Betrieb¶

Kubernetes-Deployment¶

Kafka auf Kubernetes via Strimzi Operator, Flink via Flink Operator — beide mit deklarativer Konfiguration und automatisiertem Lifecycle-Management.

CI/CD für Streaming Jobs¶

1. Schema-Validierung — CI prüft Schema-Kompatibilität
2. Integrationstests — Testcontainers mit eingebettetem Kafka + Flink MiniCluster
3. Canary Deployment — neuer Job liest von Production Topic, schreibt in Shadow Topic
4. Savepoint -> Upgrade — Flink Savepoint, neue Version deployen, fortsetzen
5. Rollback-Plan — vorherigen Savepoint behalten, zurückrollen wenn Metriken degradieren

Alternativen und wann man sie in Betracht ziehen sollte¶

Technologie	Wann statt Kafka+Flink
Redpanda	Drop-in Kafka-Ersatz, niedrigere Latenz, einfacherer Betrieb
Apache Pulsar	Multi-Tenancy, Geo-Replikation, natives Tiered Storage
Materialize	SQL-first Streaming (Postgres Wire Protocol)
RisingWave	Cloud-native Streaming DB, SQL-Interface
Kafka Streams	Einfache Transformationen ohne separaten Cluster

Fazit¶

Kafka + Flink bleiben der De-facto-Standard für Enterprise Streaming im Jahr 2026. Der KRaft-Modus hat die ZooKeeper-Abhängigkeit eliminiert, Tiered Storage senkt die Kosten, und Flink 1.18+ bringt bessere Exactly-once-Semantik und schnelleres Checkpointing.

Schlüssel zum Erfolg: - Schema-first Design — Schemas sind der Vertrag zwischen Teams - Observability von Anfang an — nicht als nachträglicher Einfall - State Management — die größte Fehlerquelle, investieren Sie in Tests - Capacity Planning — Kafka Partition Count kann nicht einfach geändert werden

CORE SYSTEMS hilft Unternehmen beim Design und Betrieb von Streaming-Architekturen vom Proof-of-Concept bis zum Produktionseinsatz mit Millionen von Events pro Sekunde.

---

Brauchen Sie Hilfe beim Design einer Streaming-Architektur? Kontaktieren Sie uns für eine Beratung.