Sanntids omsetningsanalyse over millioner av transaksjoner/dag: hvordan?

Question

IT Interview Practice · Accepted Answer

**Stream transaksjonene gjennom Kafka inn i en stream-prosessor som pre-aggregerer til en OLAP-store, slik at dashboards leser bittesmå ferdigberegnede rollups i stedet for å skanne rå events.** Ved millioner txns/dag kjører du aldri `SUM()` over rå-tabellen ved hvert sidelast — 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-minutt rollups)     (les)
                                                         └─▶ S3/Parquet (rå, replay/audit)
                                     state store ◀──────────┘  (exactly-once checkpoints)
```

## Slik fungerer det

- **Kafka** er den varige loggen. Hver betaling publiserer et event (`amount`, `currency`, `ts`, `merchant`). Den buffrer spikes, avkobler produsenter fra consumers, og lar deg **replaye** historikk for å gjenoppbygge aggregeringer.
- **Stream-prosessor (Flink / Kafka Streams)** holder **tumbling/sliding windows** (per minutt/time) og folder hvert event inn i en løpende total i sitt **state store**. Output er en pre-aggregert rad per (minutt, dimensjon).
- **OLAP-store (ClickHouse, Druid, Pinot)** lagrer de rollup-ene columnar. Et dashboard som spør "omsetning siste 24t" skanner ~1 440 rader, ikke millioner — under sekundet.
- **Materialized views** i ClickHouse kan gjøre samme rollup inne i DB-en (`AggregatingMergeTree`) hvis du vil ha færre bevegelige deler.

## Intervjuperspektiv

Intervjueren undersøker om du **pre-aggregerer ved write vs skanner ved lesning**, og om du forstår **exactly-once**. Gode svar navngir Kafka + OLAP; utmerkede svar forklarer **hvorfor sene/duplikate events korrumperer totaler** og hvordan man fikser dem: idempotente nøkler, Flink **checkpointing + transactional sink** for exactly-once, og **watermarks** for å lukke windows til tross for sene ankomster. En vanlig felle er å foreslå `SELECT SUM()` på Postgres — greit ved tusenvis/dag, det kollapser ved millioner.

## Avveininger og feil

- **Lambda vs Kappa.** Lambda kjører et batch-lag (nattlig Spark avstemmer sannhetskilden) ved siden av stream-laget (raskt men tilnærmet) — nøyaktig men to kodebaser. **Kappa** bruker kun stream-laget og **replayer Kafka** for å fikse bugs — enklere, én kodebase, nå den vanlige standarden.
- **Exactly-once er ikke gratis.** Transactional sinks legger til latency og throughput-kostnad; mange team aksepterer **at-least-once + idempotente upserts** nøklet på `txn_id` i stedet.
- **Sen data.** En betaling som settles 2t sent lander etter at windowen dens lukket. Watermarks + allowed-lateness gjenåpner windows, eller en nattlig batch-jobb korrigerer gårsdagens tall.
- **Multi-currency / refunds** må modelleres som fortegnede events, ellers drifter "omsetning".
- **Når ikke:** noen få tusen txns/dag trenger ingenting av dette — en Postgres rollup-tabell oppdatert av en cron slår en Kafka+Flink-klynge du må drifte.

Arkitektur

Slik fungerer det

Intervjuperspektiv

Avveininger og feil

Relaterte spørsmål