Real-time analytika tržeb nad miliony transakcí denně: jak na to?

Question

IT Interview Practice · Accepted Answer

**Streamujte transakce přes Kafku do stream procesoru, který předagreguje do OLAP storu, takže dashboardy čtou drobné předpočítané rollupy místo skenování syrových událostí.** Při milionech transakcí/den nikdy nespouštíte `SUM()` nad syrovou tabulkou při každém načtení stránky — agregujete jednou, při zápisu.

## Architektura

```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)
```

## Jak to funguje

- **Kafka** je trvanlivý log. Každá platba publikuje událost (`amount`, `currency`, `ts`, `merchant`). Bufferuje špičky, odděluje producenty od consumerů a umožňuje **replay** historie pro přebudování agregátů.
- **Stream procesor (Flink / Kafka Streams)** udržuje **tumbling/sliding okna** (na minutu/hodinu) a skládá každou událost do běžícího součtu ve svém **state store**. Výstupem je předagregovaný řádek na (minuta, dimenze).
- **OLAP store (ClickHouse, Druid, Pinot)** ukládá tyto rollupy columnar. Dashboard dotazující „tržby za posledních 24 h“ skenuje ~1 440 řádků, ne miliony — sub-sekunda.
- **Materializované pohledy** v ClickHouse mohou stejný rollup dělat uvnitř DB (`AggregatingMergeTree`), pokud chcete méně pohyblivých částí.

## Pohled z pohovoru

Tazatel zkoumá, zda **předagregujete při zápisu vs skenujete při čtení** a zda chápete **exactly-once**. Dobré odpovědi pojmenují Kafka + OLAP; skvělé vysvětlí, **proč pozdní/duplicitní události kazí součty** a jak to opravit: idempotenční klíče, Flink **checkpointing + transakční sink** pro exactly-once a **watermarky** k uzavření oken navzdory pozdním příchodům. Častou pastí je navrhnout `SELECT SUM()` nad Postgresem — v pořádku při tisících/den, při milionech se zhroutí.

## Kompromisy a selhání

- **Lambda vs Kappa.** Lambda spouští batch vrstvu (noční Spark srovnává zdroj pravdy) vedle stream vrstvy (rychlá, ale přibližná) — přesné, ale dvě codebase. **Kappa** používá jen stream vrstvu a **přehrává Kafku** k opravě bugů — jednodušší, jedna codebase, dnes běžný default.
- **Exactly-once není zdarma.** Transakční sinky přidávají latenci a náklad na throughput; mnoho týmů místo toho akceptuje **at-least-once + idempotentní upserty** klíčované `txn_id`.
- **Pozdní data.** Platba usazená o 2 h později dopadne poté, co se její okno uzavřelo. Watermarky + allowed-lateness okna znovuotevřou, nebo noční batch job opraví včerejší čísla.
- **Multi-currency / refundy** musí být modelovány jako signované události, jinak „tržby“ ujedou.
- **Kdy ne:** pár tisíc transakcí/den nepotřebuje nic z toho — Postgres rollup tabulka aktualizovaná cronem porazí Kafka+Flink cluster, který musíte provozovat.

Architektura

Jak to funguje

Pohled z pohovoru

Kompromisy a selhání

Související otázky