Analitikë të ardhurash në kohë reale mbi miliona transaksione/ditë: si?

Question

IT Interview Practice · Accepted Answer

**Bëni stream të transaksioneve përmes Kafka në një stream processor që pre-agregon në një OLAP store, kështu që dashboards lexojnë rollup-e të vockla të para-llogaritura në vend që të skanojnë event-et e papërpunuara.** Në miliona txns/ditë kurrë nuk ekzekutoni `SUM()` mbi tabelën e papërpunuar në çdo ngarkim faqeje — agregoni një herë, në shkrim.

## Arkitektura

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

## Si funksionon

- **Kafka** është log-u i qëndrueshëm. Çdo pagesë publikon një event (`amount`, `currency`, `ts`, `merchant`). Ai buffer-on spikes, bën decouple të prodhuesve nga consumers, dhe ju lejon të bëni **replay** të historisë për të rindërtuar agregatet.
- **Stream processor (Flink / Kafka Streams)** mban **tumbling/sliding windows** (për minutë/orë) dhe fut çdo event në një total të vazhdueshëm në **state store**-in e vet. Output-i është një rresht i para-agreguar për (minutë, dimension).
- **OLAP store (ClickHouse, Druid, Pinot)** i ruan ato rollup-e në columnar. Një dashboard që interrogon "të ardhurat 24h të fundit" skanon ~1,440 rreshta, jo miliona — nën-sekondë.
- **Materialized views** në ClickHouse mund të bëjnë të njëjtin rollup brenda DB-së (`AggregatingMergeTree`) nëse doni më pak pjesë lëvizëse.

## Këndvështrimi i intervistës

Intervistuesi heton nëse **pre-agregoni në shkrim vs skanoni në lexim**, dhe nëse e kuptoni **exactly-once**. Përgjigjet e mira emërtojnë Kafka + OLAP; përgjigjet e shkëlqyera shpjegojnë **pse event-et e vonuara/të dyfishta e prishin totalet** dhe si t'i rregulloni: idempotent keys, Flink **checkpointing + transactional sink** për exactly-once, dhe **watermarks** për të mbyllur windows pavarësisht mbërritjeve të vona. Një kurth i zakonshëm është të propozosh `SELECT SUM()` në Postgres — në rregull në mijëra/ditë, shkrihet në miliona.

## Kompromiset & gabimet

- **Lambda vs Kappa.** Lambda ekzekuton një batch layer (Spark natën rakordon burimin e së vërtetës) pranë stream layer (i shpejtë por i përafërt) — i saktë por dy codebases. **Kappa** përdor vetëm stream layer dhe **bën replay të Kafka** për të rregulluar bugs — më i thjeshtë, një codebase, tani default-i i zakonshëm.
- **Exactly-once nuk është falas.** Transactional sinks shtojnë latency dhe kosto throughput; shumë ekipe pranojnë **at-least-once + idempotent upserts** të indeksuar sipas `txn_id` në vend të kësaj.
- **Të dhëna të vona.** Një pagesë që fiksohet 2h vonë mbërrin pasi window-i i saj është mbyllur. Watermarks + allowed-lateness rihapin windows, ose një batch job natën korrigjon numrat e djeshëm.
- **Multi-currency / refunds** duhet të modelohen si event-e me shenjë, përndryshe "të ardhurat" rrëshqasin.
- **Kur jo:** disa mijëra txns/ditë nuk kanë nevojë për asnjë prej këtyre — një Postgres rollup table i përditësuar nga një cron mund të mundë një klaster Kafka+Flink që duhet ta operoni.

Arkitektura

Si funksionon

Këndvështrimi i intervistës

Kompromiset & gabimet

Pyetje të ngjashme