Echtzeit-Umsatzanalyse über Millionen Transaktionen/Tag: wie?

Question

IT Interview Practice · Accepted Answer

**Streame die Transaktionen durch Kafka in einen Stream-Prozessor, der in einen OLAP-Store vor-aggregiert, sodass Dashboards winzige vorberechnete Rollups lesen statt Roh-Events zu scannen.** Bei Millionen Txns/Tag führst du niemals bei jedem Seitenaufruf ein `SUM()` über die Roh-Tabelle aus - du aggregierst einmal, beim Write.

## Architektur

```text
Payment svc ──▶ Kafka topic ──▶ Flink/Kafka Streams ──┬─▶ OLAP (ClickHouse/Druid)  ◀── Dashboard
 (txn events)   (buffer,replay)   (windowed pre-agg)    │      (per-minute rollups)     (read)
                                                         └─▶ S3/Parquet (raw, replay/audit)
                                     state store ◀──────────┘  (exactly-once checkpoints)
```

## Wie es funktioniert

- **Kafka** ist das langlebige Log. Jede Zahlung publiziert ein Event (`amount`, `currency`, `ts`, `merchant`). Es puffert Spitzen, entkoppelt Producer von Consumern und lässt dich Historie **replayen**, um Aggregate neu aufzubauen.
- **Stream-Prozessor (Flink / Kafka Streams)** hält **Tumbling/Sliding Windows** (pro Minute/Stunde) und faltet jedes Event in eine laufende Summe in seinem **State Store**. Ausgabe ist eine vor-aggregierte Row pro (Minute, Dimension).
- **OLAP-Store (ClickHouse, Druid, Pinot)** speichert diese Rollups columnar. Ein Dashboard, das "Umsatz letzte 24h" abfragt, scannt ~1.440 Rows, nicht Millionen - sub-Sekunde.
- **Materialized Views** in ClickHouse können denselben Rollup innerhalb der DB machen (`AggregatingMergeTree`), wenn du weniger bewegliche Teile willst.

## Interview-Perspektive

Der Interviewer sondiert, ob du **beim Write vor-aggregierst vs. beim Read scannst**, und ob du **Exactly-once** verstehst. Gute Antworten benennen Kafka + OLAP; hervorragende Antworten erklären, **warum späte/doppelte Events Summen verfälschen** und wie man sie behebt: idempotente Keys, Flink **Checkpointing + transactional Sink** für Exactly-once, und **Watermarks**, um Windows trotz später Ankünfte zu schließen. Eine häufige Falle ist der Vorschlag, `SELECT SUM()` auf Postgres zu machen - bei Tausenden/Tag in Ordnung, kollabiert es bei Millionen.

## Trade-offs & Fehler

- **Lambda vs. Kappa.** Lambda betreibt eine Batch-Schicht (nächtliches Spark gleicht die Source of Truth ab) neben der Stream-Schicht (schnell, aber näherungsweise) - genau, aber zwei Codebases. **Kappa** nutzt nur die Stream-Schicht und **replayt Kafka**, um Bugs zu beheben - einfacher, eine Codebase, inzwischen der übliche Default.
- **Exactly-once ist nicht kostenlos.** Transactional Sinks kosten Latency und Throughput; viele Teams akzeptieren stattdessen **At-least-once + idempotente Upserts**, gekeyt auf `txn_id`.
- **Späte Daten.** Eine Zahlung, die 2h zu spät settelt, landet nach Schließung ihres Windows. Watermarks + Allowed-Lateness öffnen Windows erneut, oder ein nächtlicher Batch-Job korrigiert die gestrigen Zahlen.
- **Multi-Currency / Rückerstattungen** müssen als signierte Events modelliert werden, sonst driftet der "Umsatz".
- **Wann nicht:** ein paar Tausend Txns/Tag brauchen nichts davon - eine per Cron aktualisierte Postgres-Rollup-Tabelle schlägt ein Kafka+Flink-Cluster, das du betreiben musst.

Architektur

Wie es funktioniert

Interview-Perspektive

Trade-offs & Fehler

Ähnliche Fragen