Event-Streaming-Architektur in der Cloud: Praktischer Leitfaden für Platform-Engineers

Event-Streaming ist längst keine Nischen-Capability mehr für High-Frequency-Trading oder Social-Media-Giganten. Heute ist es das Rückgrat moderner cloud-nativer Data-Plattformen — es ermöglicht Real-time-Analytics, Microservice-Entkopplung, Change Data Capture und operative Intelligence in Größenordnung. Dieser Leitfaden führt durch die Architektur-Entscheidungen, Deployment-Patterns und operativen Realitäten beim Bau von Event-Streaming-Infrastruktur in der Cloud.

TL;DR

• Warum Streaming? Batch-ETL produziert per Design Latenz — moderne Use-Cases (Fraud-Detection, Operational Monitoring) brauchen Sub-Sekunden
• Plattform-Wahl: Kinesis (AWS), Pub/Sub (GCP), Event Hubs (Azure) oder MSK/Strimzi für Kafka-Portabilität
• Schema-Registry ist non-negotiable — JSON ohne Versionierung ist ein Production-Disaster
• Exactly-once ist möglich aber teuer — für Analytics meist At-least-once mit idempotenten Sinks ausreichend
• Multi-Region: MirrorMaker 2 für Disaster-Recovery, Topic-Namespacing gegen Replication-Loops

Warum Event-Streaming?

Klassische Batch-ETL-Pipelines bringen per Design Latenz mit. Daten, die über den Tag gesammelt werden, laufen nachts durch und sind morgens im Dashboard. Für viele Use-Cases der 2010er war das okay. 2026 ist die Lage fundamental anders:

• Real-time Fraud-Detection braucht Sub-Sekunden-Entscheidungen
• Operational Monitoring muss Anomalien zeigen, bevor sie zum Incident werden
• Microservice-Choreografie verlangt entkoppelte, asynchrone Kommunikation
• Event Sourcing braucht unveränderbares Audit-Log mit Replay-Fähigkeit

Event-Streaming löst all das, indem Daten als kontinuierliches, geordnetes Log von Facts behandelt werden — nicht als Zeilen in einer Tabelle.

Kernkonzepte

Bevor du dich für eine Plattform entscheidest, müsst ihr euch auf Begriffe einigen:

Cloud-Plattform-Vergleich

Drei große Managed-Event-Streaming-Services dominieren Cloud-Deployments:

Für Teams mit Kafka-Expertise und Multi-Cloud-Ambitionen liefert Amazon MSK oder ein self-managed Kafka-Cluster auf Kubernetes (via Strimzi) die portabelste Lösung.

Referenz-Architektur

Das folgende Diagramm zeigt eine Production-grade Event-Streaming-Topologie für eine geopolitische Intelligence-Plattform:

graph TD
    subgraph Sources
        A[News APIs] --> K1[Kafka Topic: raw.news]
        B[Social Feeds] --> K2[Kafka Topic: raw.social]
        C[Sensor / IoT] --> K3[Kafka Topic: raw.sensors]
    end

    subgraph Stream Processing
        K1 --> SP[Flink / Kafka Streams]
        K2 --> SP
        K3 --> SP
        SP --> K4[Kafka Topic: enriched.events]
        SP --> K5[Kafka Topic: alerts.critical]
    end

    subgraph Consumers
        K4 --> DL[Delta Lake / S3]
        K4 --> ES[Elasticsearch]
        K5 --> SVC[Alert Service]
        K5 --> PG[PostgreSQL - materialized view]
    end

    subgraph Ops
        K4 --> MON[Prometheus + Grafana]
        SR[Schema Registry] -.->|validates| SP
    end

Diese Architektur trennt Verantwortlichkeiten sauber:

• Raw Topics empfangen unvalidierte High-Volume-Ingestion
• Stream Processors reichern an, filtern und validieren in-flight
• Downstream-Consumer materialisieren Views passend zu jedem Service

Provisioning mit Terraform

Hier eine minimale Terraform-Konfiguration für einen MSK-Cluster auf AWS:

resource "aws_msk_cluster" "harbinger_events" {
  cluster_name           = "harbinger-events"
  kafka_version          = "3.5.1"
  number_of_broker_nodes = 3

  broker_node_group_info {
    instance_type   = "kafka.m5.large"
    client_subnets  = var.private_subnet_ids
    security_groups = [aws_security_group.msk.id]

    storage_info {
      ebs_storage_info {
        volume_size = 1000
      }
    }
  }

  encryption_info {
    encryption_in_transit {
      client_broker = "TLS"
      in_cluster    = true
    }
  }

  configuration_info {
    arn      = aws_msk_configuration.main.arn
    revision = aws_msk_configuration.main.latest_revision
  }

  tags = {
    Environment = "production"
    Team        = "platform"
  }
}

resource "aws_msk_configuration" "main" {
  name              = "harbinger-kafka-config"
  kafka_versions    = ["3.5.1"]
  server_properties = <<-EOF
    auto.create.topics.enable=false
    default.replication.factor=3
    min.insync.replicas=2
    num.partitions=12
    log.retention.hours=168
    compression.type=lz4
  EOF
}

Schema Registry und Schema-Evolution

Untypisierte JSON-Events sind ein Production-Disaster mit Ansage. Jede Schema-Änderung wird zur Breaking Change, und historische Messages lassen sich nicht zuverlässig abfragen.

Setze Apache Avro mit Confluent Schema Registry ein, für:

• Backward Compatibility: neue Consumer können alte Messages lesen
• Forward Compatibility: alte Consumer können neue Messages lesen
• Schema-on-read: kompakter Binär-Storage, Schema wird beim Lesen aufgelöst

Beispiel-Avro-Schema für ein geopolitisches Event:

{
  "type": "record",
  "name": "GeopoliticalEvent",
  "namespace": "com.harbinger.events",
  "fields": [
    {"name": "event_id", "type": "string"},
    {"name": "timestamp", "type": "long", "logicalType": "timestamp-millis"},
    {"name": "country_code", "type": "string"},
    {"name": "event_type", "type": {"type": "enum", "name": "EventType", "symbols": ["CONFLICT", "ELECTION", "SANCTION", "PROTEST", "NATURAL_DISASTER"]}},
    {"name": "severity", "type": "float"},
    {"name": "source_url", "type": ["null", "string"], "default": null}
  ]
}

Registriere es per CLI:

curl -X POST http://schema-registry:8081/subjects/geopolitical-events-value/versions   -H "Content-Type: application/vnd.schemaregistry.v1+json"   -d '{"schema": "{"type":"record","name":"GeopoliticalEvent",...}"}'

Consumer-Patterns

Fan-Out

Ein Topic, mehrere unabhängige Consumer-Groups. Jede Group hält ihren eigenen Offset. Einsatz für:

• Parallele Processing-Pipelines (Analytics vs. Alerting)
• Unterschiedliche SLAs (real-time vs. Batch)

CQRS Read Models

Konsumiere einen Event-Stream und materialisiere query-optimierte Read-Modelle in separaten Datenbanken. Das entkoppelt Write-Throughput von Read-Performance.

Dead Letter Queue (DLQ)

Konfiguriere immer ein DLQ-Topic für Messages, die beim Processing fehlschlagen. Strukturiere es identisch zum Main-Topic, mit einem zusätzlichen Header für den Error-Grund. Das ermöglicht:

• Non-blocking Failure-Handling
• Forensik-Replay nach Bug-Fixes
• Alerting auf Error-Rate-Thresholds

# Kafka Streams Error-Handler-Config
processing.exception.handler: org.apache.kafka.streams.errors.LogAndContinueExceptionHandler
default.deserialization.exception.handler: org.apache.kafka.streams.errors.LogAndContinueExceptionHandler

Operatives Runbook

Wichtige Metriken zum Monitoring

Lag-Alerting mit Prometheus

- alert: KafkaConsumerLagHigh
  expr: kafka_consumer_group_lag > 50000
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Consumer group {{ $labels.group }} is lagging on topic {{ $labels.topic }}"
    description: "Lag is {{ $value }} messages. Investigate consumer throughput."

Exactly-once in der Praxis

Kafka unterstützt Exactly-once end-to-end, wenn:

1. Producer im Idempotent Mode laufen (enable.idempotence=true)
2. Producer Transactions für atomic Multi-Topic-Writes nutzen
3. Consumer den read_committed Isolation-Level nutzen

Für Flink auf AWS (via Kinesis Data Analytics oder self-managed):

execution.checkpointing.interval: 60s
execution.checkpointing.mode: EXACTLY_ONCE
state.backend: rocksdb
state.checkpoints.dir: s3://my-bucket/flink-checkpoints

Exactly-once ist teurer (höhere Latenz, mehr Koordinations-Overhead). Reserviere es für Financial-Transaktionen, Billing-Events und Audit-Trails. Für Analytics-Workloads reicht meist At-least-once mit idempotenten Downstream-Sinks (Upsert per event_id).

Multi-Region und Disaster-Recovery

Für globale Plattformen ermöglicht MirrorMaker 2 (MM2) Cross-Cluster-Replikation:

# MirrorMaker 2 starten
./bin/connect-mirror-maker.sh mm2.properties

# mm2.properties
clusters = us-east-1, eu-west-1
us-east-1.bootstrap.servers = broker1.us-east-1:9092
eu-west-1.bootstrap.servers = broker1.eu-west-1:9092
us-east-1->eu-west-1.enabled = true
us-east-1->eu-west-1.topics = .*
replication.factor = 3

Für Active-Active-Topologien nutze Topic-Namespacing, um Replication-Loops zu vermeiden (us-east-1.topic-name vs. eu-west-1.topic-name).

Kosten-Optimierung

Event-Streaming-Kosten können ohne Disziplin explodieren. Wichtige Hebel:

• Compression: LZ4 liefert gutes Kompressions-Verhältnis bei minimalem CPU-Overhead. Erwarte 3–5× Reduktion bei JSON-Payloads.
• Tiered Storage: MSK Tiered Storage lagert Cold-Partitions nach S3 aus und reduziert Broker-EBS-Kosten um bis zu 60 %.
• Partition-Sizing: Over-Partitioning verschwendet Broker-Ressourcen. Zielwert: 1–3 Partitionen pro Consumer-Core bei Peak-Load.
• Retention-Tuning: Setze Retention auf dein SLA, nicht auf unendlich. Die meisten Analytics-Pipelines brauchen nur 7–30 Tage Raw-Events.

DACH-Spezifika

• DSGVO und Datenresidenz: Bei EU-personenbezogenen Daten musst du die Region kontrollieren. Kafka-Topics mit personenbezogenen Daten gehören in eu-central-1 (Frankfurt) oder europe-west3 (Frankfurt) — nicht unkontrolliert in US-Regionen replizieren.
• Recht auf Vergessenwerden: Append-only Event-Logs sind dafür nicht trivial. Lösung: Pseudonymisierung der personenbezogenen Felder mit Schlüssel-Rotation, sodass Re-Identifikation nicht möglich ist.
• AVV mit Cloud-Providern: AWS, GCP und Azure bieten EU-konforme Auftragsverarbeitungsverträge (Standard Contractual Clauses).

FAQ

Wann Kafka, wann Kinesis/Pub/Sub? Kafka, wenn du Multi-Cloud-Portabilität, Replay über lange Zeiträume und Kafka-Ökosystem brauchst. Cloud-native Services, wenn du tief in einem Provider integriert bist und Ops-Aufwand minimieren willst.

Was ist der Unterschied zwischen MSK und Strimzi? MSK ist AWS-managed Kafka — du gibst Cluster-Config vor, AWS betreibt Broker, Patches, Upgrades. Strimzi ist ein Kubernetes-Operator — maximale Kontrolle, du betreibst selbst, portabel.

Wie groß sollten Topics partitioniert sein? Faustregel: 1–3 Partitionen pro Consumer-Core bei Peak-Load. Über-Partitionierung erhöht Broker-Last und Rebalance-Zeiten.

Lohnt sich Confluent Cloud gegenüber MSK? Confluent Cloud ist deutlich teurer, bietet dafür Schema Registry, ksqlDB und Multi-Cloud out-of-the-box. Bei kleinen Teams mit Kafka-Expertise oft Verschwendung — bei Enterprise-Setups mit Tools-Bedarf sinnvoll.

Fazit

Event-Streaming in der Cloud verlangt durchdachte Architektur-Entscheidungen über Ingestion, Processing, Schema-Management und Operations hinweg. Die Plattform, die das richtig macht, gewinnt einen dauerhaften Vorteil: Real-time Intelligence, resiliente Entkopplung und ein auditierbares Protokoll von allem, was passiert ist.

Stand: 14. Mai 2026.