Real-time Streaming s Apache Kafka a Flink: Architektura pro 2026¶

Real-time zpracování dat přestalo být luxusem. V roce 2026 je to základní požadavek pro fraud detection, trading systémy, IoT telemetrii i personalizaci zákaznické zkušenosti. Apache Kafka a Apache Flink tvoří páteř většiny produkčních streaming architektur.

Proč Kafka + Flink?¶

Kafka funguje jako distribuovaný commit log — spolehlivé, škálovatelné úložiště eventů s garancí pořadí. Flink je stateful stream processor s exactly-once sémantikou a sub-sekundovou latencí.

Společně pokrývají celý pipeline:

• Ingest → Kafka (producenti, konektory, CDC)
• Process → Flink (transformace, agregace, windowing, pattern detection)
• Serve → Kafka → konzumenti (databáze, API, dashboardy, alerting)

Referenční architektura¶

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

Kafka Cluster — Best Practices 2026¶

Sizing: - Minimálně 3 brokeři pro produkci (5+ pro high-throughput) - KRaft mode (bez ZooKeeper) — od Kafka 3.5+ je production-ready - Tiered Storage pro cost-effective retenci (hot/warm/cold)

Topic design: - Partition count = expected throughput / partition throughput (~10 MB/s per partition) - Replication factor 3 (min.insync.replicas=2) - Compacted topics pro state/lookup data - Naming konvence: {domain}.{entity}.{version} (např. trading.orders.v2)

Schema management: - Confluent Schema Registry (Avro/Protobuf) - Schema evolution = backward + forward compatible - Nikdy neměnit typ pole, pouze přidávat optional fields

# Kafka producer config pro low-latency trading
acks: all
linger.ms: 5
batch.size: 65536
compression.type: lz4
max.in.flight.requests.per.connection: 5
enable.idempotence: true

Flink Jobs — Production Patterns¶

Windowing strategie:

// Tumbling window — fixní intervaly (např. 1-minutové agregace)
stream
    .keyBy(event -> event.getSymbol())
    .window(TumblingEventTimeWindows.of(Time.minutes(1)))
    .aggregate(new VWAPAggregator());

// Sliding window — překrývající se okna (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 — dynamické okna podle aktivity
stream
    .keyBy(event -> event.getUserId())
    .window(EventTimeSessionWindows.withGap(Time.minutes(30)))
    .process(new SessionAnalyzer());

Watermarks a late data: - Watermark = progress indicator pro event time - BoundedOutOfOrdernessWatermarks s tolerancí 5-30 sekund - Late data → side output pro pozdější zpracování - Nikdy nespoléhat na processing time pro business logiku

State management: - RocksDB state backend pro velký state (TB+) - Incremental checkpointing (interval 1-5 minut) - State TTL pro automatický cleanup starých klíčů - Savepoints před každým deploymentem

Enterprise Use Cases¶

1. Fraud Detection (< 100ms latency)¶

Transakce → Kafka → Flink CEP (Complex Event Processing)
                         │
                         ├── Pattern: 5+ transakcí > 10K CZK za 10 min
                         ├── Pattern: nový device + vysoká částka
                         └── Pattern: geografická anomálie (2 země za 5 min)
                         │
                         ▼
                    Alert → Block → Review

Flink CEP (Complex Event Processing) umožňuje deklarativní definici fraud patternů přímo v kódu. Real-world systémy kombinují rule-based CEP s ML modelem (feature store plněný Flinkem, inference v reálném čase).

2. Trading & Market Data¶

Exchange feeds → Kafka (partitioned by symbol)
                    │
                    ▼
              Flink Jobs:
              ├── VWAP kalkulace (1s/5s/1m windows)
              ├── Order book reconstruction
              ├── Spread monitoring + alerting
              ├── Regime detection (vol clustering)
              └── Signal generation → Order Management System

Klíčové metriky: - End-to-end latence: < 10ms (intra-DC) - Throughput: 1M+ events/sec per topic - State: order book per symbol (~100KB), celkem GB

3. IoT Telemetrie & Prediktivní Údržba¶

Tisíce senzorů → Kafka (MQTT bridge) → Flink: - Anomaly detection na senzorových datech - Rolling statistics (avg, p95, p99 per device) - Prediktivní modely (feature extraction → ML serving) - Alert eskalace (warning → critical → shutdown)

4. Real-time Personalizace¶

E-commerce / content platformy: - User clickstream → Kafka → Flink → feature update - Session-level features (pages viewed, time on site, cart value) - Real-time recommendation model update - A/B test metriky v reálném čase

Monitoring & Observability¶

Kafka metriky (must-have)¶

Metrika	Alert threshold	Význam
UnderReplicatedPartitions	> 0	Data at risk
ActiveControllerCount	≠ 1	Split brain
ConsumerGroupLag	> 10K (závisí)	Processing falling behind
RequestQueueSize	> 100	Broker overloaded
LogFlushLatency	p99 > 100ms	Disk bottleneck

Flink metriky¶

Metrika	Alert threshold	Význam
lastCheckpointDuration	> 60s	State too large or slow disk
numRecordsOutPerSecond	drop > 50%	Processing stall
busyTimeMsPerSecond	> 900	Operator saturated
currentInputWatermark	drift > 5min	Late data issue

Stack: Prometheus + Grafana + custom dashboardy. Kafka Exporter pro JMX metriky, Flink má nativní Prometheus reporter.

Deployment & Operations¶

Kubernetes deployment¶

# Kafka na Kubernetes via Strimzi operator
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: production-cluster
spec:
  kafka:
    version: 3.7.0
    replicas: 5
    config:
      auto.create.topics.enable: false
      min.insync.replicas: 2
      log.retention.hours: 168
    storage:
      type: persistent-claim
      size: 500Gi
      class: fast-ssd
  zookeeper:
    replicas: 0  # KRaft mode

# Flink na Kubernetes via Flink Operator
apiVersion: flink.apache.org/v1beta1
kind: FlinkDeployment
metadata:
  name: trading-processor
spec:
  image: core/flink-trading:1.18
  flinkVersion: v1_18
  jobManager:
    resource:
      memory: "4096m"
      cpu: 2
  taskManager:
    resource:
      memory: "8192m"
      cpu: 4
    replicas: 3
  job:
    jarURI: local:///opt/flink/jobs/trading.jar
    parallelism: 12
    upgradeMode: savepoint

CI/CD pro streaming jobs¶

1. Schema validation — CI kontroluje kompatibilitu schémat
2. Integration testy — Testcontainers s embedded Kafka + Flink MiniCluster
3. Canary deployment — nový job čte z production topic, zapisuje do shadow topic
4. Savepoint → upgrade — Flink savepoint, deploy novou verzi, resume
5. Rollback plan — keep previous savepoint, revert pokud metriky degradují

Alternativy a kdy je zvážit¶

Technologie	Kdy místo Kafka+Flink
Redpanda	Drop-in Kafka replacement, nižší latence, jednodušší ops
Apache Pulsar	Multi-tenancy, geo-replikace, tiered storage nativně
Materialize	SQL-first streaming (Postgres wire protocol)
RisingWave	Cloud-native streaming DB, SQL interface
Kafka Streams	Jednoduché transformace bez separátního clusteru

Závěr¶

Kafka + Flink zůstávají de facto standardem pro enterprise streaming v roce 2026. KRaft mode eliminoval ZooKeeper dependency, Tiered Storage snižuje náklady, a Flink 1.18+ přináší lepší exactly-once a rychlejší checkpointing.

Klíč k úspěchu: - Schema-first design — schémata jsou kontrakt mezi týmy - Observability od začátku — ne jako afterthought - State management — největší source of bugs, investujte do testování - Capacity planning — Kafka partition count nelze snadno změnit

CORE SYSTEMS pomáhá firmám navrhovat a provozovat streaming architektury od proof-of-concept po produkční nasazení s miliony eventů za sekundu.

---

Potřebujete pomoc s návrhem streaming architektury? Kontaktujte nás pro konzultaci.