Real-time revenue analytics fuq miljuni ta' tranżazzjonijiet/kuljum: kif?

Question

IT Interview Practice · Accepted Answer

**Agħmel stream tat-tranżazzjonijiet permezz ta' Kafka ġo stream processor li jagħmel pre-aggregate ġo OLAP store, biex id-dashboards jaqraw rollups żgħar prekalkulati minflok jagħmlu scan ta' events mhux ipproċessati.** B'miljuni ta' txn/kuljum qatt ma tagħmel `SUM()` fuq it-table mhux ipproċessat f'kull page load — taggrega darba, mal-kitba.

## Arkitettura

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

## Kif jaħdem

- **Kafka** huwa l-log durabbli. Kull ħlas jippubblika event (`amount`, `currency`, `ts`, `merchant`). Jagħmel buffer tal-spikes, jiddekja l-producers mill-consumers, u jħallik tagħmel **replay** tal-istorja biex tibni mill-ġdid l-aggregati.
- **Stream processor (Flink / Kafka Streams)** iżomm **tumbling/sliding windows** (għal kull minuta/siegħa) u jgħaqqad kull event f'total kurrenti fil-**state store** tiegħu. L-output huwa row prekalkulat għal kull (minuta, dimensjoni).
- **OLAP store (ClickHouse, Druid, Pinot)** jaħżen dawk ir-rollups columnar. Dashboard li tagħmel query "revenue fl-aħħar 24h" jagħmel scan ta' ~1,440 row, mhux miljuni — sub-sekonda.
- **Materialized views** f'ClickHouse jistgħu jagħmlu l-istess rollup ġewwa d-DB (`AggregatingMergeTree`) jekk trid inqas biċċiet li jiċċaqilqu.

## Perspettiva tal-intervista

L-intervistatur jgħarbel jekk tagħmilx **pre-aggregate mal-kitba vs scan mal-qari**, u jekk tifhimx **exactly-once**. Tweġibiet tajbin isemmu Kafka + OLAP; tweġibiet eċċellenti jispjegaw **għaliex events tard/duplikati jkorrompu t-totals** u kif tagħmilhom tajbin: idempotent keys, Flink **checkpointing + transactional sink** għal exactly-once, u **watermarks** biex jagħlqu l-windows minkejja wasliet tard. Nassa komuni hija li tipproponi `SELECT SUM()` fuq Postgres — tajjeb b'eluf/kuljum, jinħall b'miljuni.

## Trade-offs u fallimenti

- **Lambda vs Kappa.** Lambda jħaddem batch layer (Spark ta' bil-lejl jirrikonċilja s-source of truth) ħdejn l-istream layer (mgħaġġel imma approssimattiv) — akkurat imma żewġ codebases. **Kappa** juża biss l-istream layer u **jagħmel replay ta' Kafka** biex jaġġusta bugs — aktar sempliċi, codebase wieħed, issa d-default komuni.
- **Exactly-once mhux b'xejn.** Transactional sinks iżidu latenza u kost ta' throughput; ħafna teams jaċċettaw **at-least-once + idempotent upserts** ibbażati fuq `txn_id` minflok.
- **Data tard.** Ħlas li jissetilja 2h tard jasal wara li għalqet il-window tiegħu. Watermarks + allowed-lateness jerġgħu jiftħu l-windows, jew batch job ta' bil-lejl jikkoreġi n-numri tal-bieraħ.
- **Multi-currency / refunds** iridu jiġu mmudellati bħala signed events, inkella r-"revenue" tiddevja.
- **Meta le:** ftit eluf ta' txn/kuljum ma jeħtieġu xejn minn dan — rollup table ta' Postgres aġġornat b'cron jirbaħ cluster ta' Kafka+Flink li trid tħaddem.

Arkitettura

Kif jaħdem

Perspettiva tal-intervista

Trade-offs u fallimenti

Mistoqsijiet relatati