Real-time omzetanalyse over miljoenen transacties per dag: hoe?

Question

IT Interview Practice · Accepted Answer

**Stream de transacties via Kafka naar een stream processor die vooraf aggregeert in een OLAP-store, zodat dashboards kleine voorberekende rollups lezen in plaats van ruwe events te scannen.** Bij miljoenen transacties/dag draai je nooit `SUM()` over de ruwe tabel bij elke page load — je aggregeert één keer, bij de write.

## Architectuur

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

## Hoe het werkt

- **Kafka** is de duurzame log. Elke betaling publiceert een event (`amount`, `currency`, `ts`, `merchant`). Het buffert pieken, ontkoppelt producers van consumers, en laat je geschiedenis **replayen** om aggregaties opnieuw te bouwen.
- **Stream processor (Flink / Kafka Streams)** houdt **tumbling/sliding windows** (per minuut/uur) bij en vouwt elk event in een lopend totaal in zijn **state store**. De output is een voorberekende row per (minuut, dimensie).
- **OLAP-store (ClickHouse, Druid, Pinot)** slaat die rollups columnar op. Een dashboard dat "omzet laatste 24u" opvraagt scant ~1.440 rows, niet miljoenen — sub-seconde.
- **Materialized views** in ClickHouse kunnen dezelfde rollup binnen de DB doen (`AggregatingMergeTree`) als je minder bewegende delen wilt.

## Interviewperspectief

De interviewer peilt of je **vooraf aggregeert bij de write versus scant bij de read**, en of je **exactly-once** begrijpt. Goede antwoorden benoemen Kafka + OLAP; uitstekende antwoorden leggen uit **waarom late/dubbele events totalen corrumperen** en hoe je ze repareert: idempotente keys, Flink **checkpointing + transactionele sink** voor exactly-once, en **watermarks** om windows te sluiten ondanks late aankomsten. Een veelvoorkomende valkuil is `SELECT SUM()` op Postgres voorstellen — prima bij duizenden/dag, het stort in bij miljoenen.

## Afwegingen & faalmodi

- **Lambda versus Kappa.** Lambda draait een batch-laag (nachtelijke Spark reconcileert de source of truth) naast de stream-laag (snel maar benaderend) — nauwkeurig maar twee codebases. **Kappa** gebruikt alleen de stream-laag en **replayt Kafka** om bugs te repareren — eenvoudiger, één codebase, nu de gebruikelijke default.
- **Exactly-once is niet gratis.** Transactionele sinks voegen latency en throughput-kosten toe; veel teams accepteren in plaats daarvan **at-least-once + idempotente upserts** op sleutel van `txn_id`.
- **Late data.** Een betaling die 2u te laat settelt, landt nadat zijn window sloot. Watermarks + allowed-lateness heropenen windows, of een nachtelijke batch-job corrigeert de cijfers van gisteren.
- **Multi-currency / refunds** moeten als signed events worden gemodelleerd, anders drift "omzet".
- **Wanneer niet:** een paar duizend transacties/dag heeft niets hiervan nodig — een Postgres rollup-tabel ge-updatet door een cron verslaat een Kafka+Flink-cluster dat je moet beheren.

Architectuur

Hoe het werkt

Interviewperspectief

Afwegingen & faalmodi

Gerelateerde vragen