Realtidsanalys av intäkter över miljontals transaktioner/dag: hur?

Question

IT Interview Practice · Accepted Answer

**Strömma transaktionerna genom Kafka in i en stream processor som föraggregerar till en OLAP-store, så att dashboards läser små förberäknade rollups istället för att scanna råa händelser.** Vid miljontals transaktioner/dag kör du aldrig `SUM()` över råtabellen vid varje sidladdning — du aggregerar en gång, vid skrivning.

## 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å här fungerar det

- **Kafka** är den hållbara loggen. Varje betalning publicerar en händelse (`amount`, `currency`, `ts`, `merchant`). Den buffrar toppar, frikopplar producenter från consumers, och låter dig **replaya** historik för att bygga om aggregat.
- **Stream processor (Flink / Kafka Streams)** håller **tumbling/sliding windows** (per minut/timme) och viker in varje händelse i en löpande total i sin **state store**. Utdata är en föraggregerad rad per (minut, dimension).
- **OLAP-store (ClickHouse, Druid, Pinot)** lagrar de rollups columnar. En dashboard som frågar "intäkt senaste 24h" scannar ~1 440 rader, inte miljoner — sub-sekund.
- **Materialized views** i ClickHouse kan göra samma rollup inuti DB:n (`AggregatingMergeTree`) om du vill ha färre rörliga delar.

## Intervjuperspektiv

Intervjuaren undersöker om du **föraggregerar vid skrivning vs scannar vid läsning**, och om du förstår **exactly-once**. Bra svar namnger Kafka + OLAP; utmärkta svar förklarar **varför sena/dubbla händelser korrumperar totaler** och hur man fixar dem: idempotenta nycklar, Flink **checkpointing + transactional sink** för exactly-once, och **watermarks** för att stänga fönster trots sena ankomster. En vanlig fälla är att föreslå `SELECT SUM()` på Postgres — okej vid tusentals/dag, kollapsar det vid miljontals.

## Avvägningar & fel

- **Lambda vs Kappa.** Lambda kör ett batch-lager (nattlig Spark stämmer av source of truth) bredvid stream-lagret (snabbt men approximativt) — noggrant men två kodbaser. **Kappa** använder bara stream-lagret och **replayar Kafka** för att fixa buggar — enklare, en kodbas, nu det vanliga standardvalet.
- **Exactly-once är inte gratis.** Transactional sinks lägger till latens och throughput-kostnad; många team accepterar istället **at-least-once + idempotenta upserts** nycklade på `txn_id`.
- **Sen data.** En betalning som settlar 2h sent landar efter att dess fönster stängt. Watermarks + allowed-lateness öppnar fönster igen, eller ett nattligt batch-jobb korrigerar gårdagens siffror.
- **Multi-valuta / återbetalningar** måste modelleras som signerade händelser, annars driver "intäkt".
- **När inte:** några tusen transaktioner/dag behöver inget av detta — en Postgres-rollup-tabell uppdaterad av en cron slår ett Kafka+Flink-kluster du måste drifta.

Arkitektur

Så här fungerar det

Intervjuperspektiv

Avvägningar & fel

Relaterade frågor