Real-time analitika prihoda preko milijuna transakcija dnevno: kako?

Question

IT Interview Practice · Accepted Answer

**Streamajte transakcije kroz Kafku u stream procesor koji pre-agregira u OLAP store, tako da dashboardi čitaju sićušne pre-računate rollupove umjesto skeniranja sirovih događaja.** Pri milijunima transakcija/dan nikada ne pokrećete `SUM()` preko sirove tablice pri svakom učitavanju stranice — agregirate jednom, pri upisu.

## Arhitektura

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

## Kako funkcionira

- **Kafka** je trajni log. Svako plaćanje objavljuje događaj (`amount`, `currency`, `ts`, `merchant`). Bufferira skokove, razdvaja producere od consumera i omogućuje **replay** povijesti za ponovnu izgradnju agregata.
- **Stream procesor (Flink / Kafka Streams)** drži **tumbling/sliding prozore** (po minuti/satu) i sklapa svaki događaj u tekući ukupni zbroj u svom **state storeu**. Izlaz je pre-agregirani redak po (minuta, dimenzija).
- **OLAP store (ClickHouse, Druid, Pinot)** pohranjuje te rollupove columnar. Dashboard koji upituje "prihod zadnjih 24 h" skenira ~1.440 redaka, ne milijune — ispod sekunde.
- **Materialized views** u ClickHouseu mogu raditi isti rollup unutar baze (`AggregatingMergeTree`) ako želite manje pokretnih dijelova.

## Perspektiva intervjua

Ispitivač ispituje radite li **pre-agregaciju pri upisu vs skeniranje pri čitanju** i razumijete li **exactly-once**. Dobri odgovori imenuju Kafka + OLAP; odlični objašnjavaju **zašto zakašnjeli/duplicirani događaji kvare zbrojeve** i kako to popraviti: idempotentni ključevi, Flink **checkpointing + transakcijski sink** za exactly-once i **watermarkovi** za zatvaranje prozora unatoč zakašnjelim dolascima. Uobičajena zamka je predlaganje `SELECT SUM()` na Postgresu — u redu pri tisućama/dan, uruši se pri milijunima.

## Kompromisi i neuspjesi

- **Lambda vs Kappa.** Lambda pokreće batch sloj (noćni Spark usklađuje izvor istine) uz stream sloj (brz ali približan) — točno ali dvije baze koda. **Kappa** koristi samo stream sloj i **replaya Kafku** za popravak bugova — jednostavnije, jedna baza koda, sada uobičajeni zadani izbor.
- **Exactly-once nije besplatan.** Transakcijski sinkovi dodaju latenciju i trošak throughputa; mnogi timovi umjesto toga prihvaćaju **at-least-once + idempotentni upsert** ključan na `txn_id`.
- **Zakašnjeli podaci.** Plaćanje koje se namiri 2 h kasnije stiže nakon što se prozor zatvorio. Watermarkovi + dopuštena zakašnjelost ponovno otvaraju prozore, ili noćni batch posao ispravi jučerašnje brojeve.
- **Više valuta / povrati** moraju se modelirati kao događaji s predznakom, inače "prihod" driftira.
- **Kada ne:** nekoliko tisuća transakcija/dan ne treba ništa od ovoga — Postgres rollup tablica koju ažurira cron pobjeđuje Kafka+Flink cluster koji morate operirati.

Arhitektura

Kako funkcionira

Perspektiva intervjua

Kompromisi i neuspjesi

Povezana pitanja