Analitik revenue real-time atas jutaan transaksi/hari: bagaimana caranya?

Question

IT Interview Practice · Accepted Answer

**Stream transaksi melalui Kafka ke dalam stream processor yang pra-agregat menjadi OLAP store, sehingga dashboard membaca rollup pra-komputasi yang kecil alih-alih men-scan event mentah.** Pada jutaan txn/hari Anda tidak pernah menjalankan `SUM()` atas tabel mentah pada setiap page load — Anda mengagregat sekali, saat write.

## Arsitektur

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

## Cara kerjanya

- **Kafka** adalah log durable. Setiap pembayaran mempublikasikan sebuah event (`amount`, `currency`, `ts`, `merchant`). Ia mem-buffer lonjakan, memisahkan producer dari consumer, dan memungkinkan Anda **replay** histori untuk membangun ulang agregat.
- **Stream processor (Flink / Kafka Streams)** memelihara **tumbling/sliding window** (per menit/jam) dan melipat setiap event ke total berjalan di **state store**-nya. Output-nya adalah baris pra-agregasi per (menit, dimensi).
- **OLAP store (ClickHouse, Druid, Pinot)** menyimpan rollup itu secara columnar. Sebuah dashboard yang mengquery "revenue 24 jam terakhir" men-scan ~1.440 baris, bukan jutaan — sub-detik.
- **Materialized views** di ClickHouse bisa melakukan rollup yang sama di dalam DB (`AggregatingMergeTree`) jika Anda ingin lebih sedikit bagian yang bergerak.

## Perspektif wawancara

Pewawancara menyelidiki apakah Anda **pra-agregat saat write vs scan saat baca**, dan apakah Anda memahami **exactly-once**. Jawaban baik menyebut Kafka + OLAP; jawaban hebat menjelaskan **mengapa event terlambat/duplikat merusak total** dan cara memperbaikinya: idempotency key, Flink **checkpointing + transactional sink** untuk exactly-once, dan **watermark** untuk menutup window meski ada kedatangan terlambat. Jebakan umum adalah mengusulkan `SELECT SUM()` di Postgres — baik pada ribuan/hari, ia runtuh pada jutaan.

## Trade-off & kegagalan

- **Lambda vs Kappa.** Lambda menjalankan batch layer (Spark malam hari merekonsiliasi sumber kebenaran) di samping stream layer (cepat tetapi perkiraan) — akurat tetapi dua basis kode. **Kappa** hanya memakai stream layer dan **me-replay Kafka** untuk memperbaiki bug — lebih sederhana, satu basis kode, kini default umum.
- **Exactly-once tidak gratis.** Transactional sink menambah latensi dan biaya throughput; banyak tim menerima **at-least-once + idempotent upsert** yang di-key oleh `txn_id`.
- **Data terlambat.** Sebuah pembayaran yang settle 2 jam terlambat mendarat setelah window-nya tertutup. Watermark + allowed-lateness membuka ulang window, atau batch job malam hari mengoreksi angka kemarin.
- **Multi-currency / refund** harus dimodelkan sebagai event bertanda (signed), jika tidak "revenue" melenceng.
- **Kapan tidak perlu:** beberapa ribu txn/hari tidak butuh ini — tabel rollup Postgres yang di-update cron mengalahkan cluster Kafka+Flink yang harus Anda operasikan.

Arsitektur

Cara kerjanya

Perspektif wawancara

Trade-off & kegagalan

Pertanyaan terkait