Real-time omsætnings-analytics over millioner af transaktioner/dag: hvordan?

Question

IT Interview Practice · Accepted Answer

**Stream transaktionerne gennem Kafka ind i en stream processor, der pre-aggregerer ind i en OLAP-store, så dashboards læser bittesmå forudberegnede rollups i stedet for at scanne rå events.** Ved millioner af txns/dag kører du aldrig `SUM()` over den rå tabel ved hver page load — du aggregerer én gang, ved write.

## Arkitektur

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

## Sådan virker det

- **Kafka** er den holdbare log. Hver betaling publicerer et event (`amount`, `currency`, `ts`, `merchant`). Den buffer spikes, decoupler producers fra consumers, og lader dig **replaye** historik for at genopbygge aggregates.
- **Stream processor (Flink / Kafka Streams)** holder **tumbling/sliding windows** (pr. minut/time) og folder hvert event ind i en løbende total i sin **state store**. Output er en pre-aggregeret row pr. (minut, dimension).
- **OLAP-store (ClickHouse, Druid, Pinot)** gemmer disse rollups columnar. Et dashboard der forespørger "omsætning sidste 24t" scanner ~1.440 rows, ikke millioner — sub-sekund.
- **Materialized views** i ClickHouse kan lave samme rollup inde i DB'en (`AggregatingMergeTree`) hvis du vil have færre bevægelige dele.

## Interview-perspektiv

Intervieweren undersøger, om du **pre-aggregerer ved write vs scanner ved read**, og om du forstår **exactly-once**. Gode svar navngiver Kafka + OLAP; fremragende svar forklarer, **hvorfor sene/duplikerede events korrumperer totaler**, og hvordan man retter dem: idempotente nøgler, Flink **checkpointing + transactional sink** for exactly-once, og **watermarks** for at lukke windows trods sene ankomster. En almindelig fælde er at foreslå `SELECT SUM()` på Postgres — fint ved tusinder/dag, det kollapser ved millioner.

## Trade-offs & fejl

- **Lambda vs Kappa.** Lambda kører et batch-lag (natlig Spark afstemmer kilden til sandhed) ved siden af stream-laget (hurtigt men omtrentligt) — nøjagtigt men to kodebaser. **Kappa** bruger kun stream-laget og **replayer Kafka** for at rette bugs — enklere, én kodebase, nu den almindelige default.
- **Exactly-once er ikke gratis.** Transactional sinks tilføjer latency og throughput-omkostning; mange teams accepterer **at-least-once + idempotent upserts** nøglet på `txn_id` i stedet.
- **Sene data.** En betaling der settles 2t sent, lander efter dens window lukkede. Watermarks + allowed-lateness genåbner windows, eller et natligt batch-job retter gårsdagens tal.
- **Multi-currency / refunds** skal modelleres som signerede events, ellers drifter "omsætning".
- **Hvornår ikke:** nogle få tusinde txns/dag kræver intet af dette — en Postgres-rollup-tabel opdateret af en cron slår en Kafka+Flink-cluster du skal drifte.

Arkitektur

Sådan virker det

Interview-perspektiv

Trade-offs & fejl

Relaterede spørgsmål