Analytics de venituri în timp real peste milioane de tranzacții/zi: cum?

Question

IT Interview Practice · Accepted Answer

**Transmite tranzacțiile prin Kafka către un stream processor care face pre-agregare într-un store OLAP, astfel încât dashboard-urile să citească rollup-uri minuscule pre-calculate în loc să scaneze evenimente brute.** La milioane de tranzacții/zi nu rulezi niciodată `SUM()` peste tabela brută la fiecare încărcare de pagină — agregezi o singură dată, la scriere.

## Arhitectură

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

## Cum funcționează

- **Kafka** este log-ul durabil. Fiecare plată publică un eveniment (`amount`, `currency`, `ts`, `merchant`). Face buffering la vârfuri, decuplează producătorii de consumeri și permite să faci **replay** la istoric pentru a reconstrui agregatele.
- **Stream processor-ul (Flink / Kafka Streams)** menține **ferestre tumbling/sliding** (per minut/oră) și pliază fiecare eveniment într-un total curent în **state store**-ul său. Rezultatul este un rând pre-agregat per (minut, dimensiune).
- **Store-ul OLAP (ClickHouse, Druid, Pinot)** stochează acele rollup-uri columnar. Un dashboard care interoghează "veniturile din ultimele 24h" scanează ~1.440 de rânduri, nu milioane — sub-secundă.
- **Materialized views** în ClickHouse pot face același rollup în interiorul DB-ului (`AggregatingMergeTree`) dacă vrei mai puține piese în mișcare.

## Perspectiva de interviu

Intervievatorul sondează dacă faci **pre-agregare la scriere vs scan la citire** și dacă înțelegi **exactly-once**. Răspunsurile bune numesc Kafka + OLAP; cele excelente explică **de ce evenimentele întârziate/duplicate corup totalurile** și cum să le repari: chei idempotente, **checkpointing + transactional sink** în Flink pentru exactly-once și **watermarks** pentru a închide ferestrele în ciuda sosirilor târzii. O capcană obișnuită este a propune `SELECT SUM()` pe Postgres — în regulă la mii/zi, se prăbușește la milioane.

## Compromisuri și eșecuri

- **Lambda vs Kappa.** Lambda rulează un strat batch (un Spark nocturn reconciliază sursa de adevăr) lângă stratul de stream (rapid, dar aproximativ) — precis, dar două baze de cod. **Kappa** folosește doar stratul de stream și **face replay la Kafka** pentru a repara bug-uri — mai simplu, o singură bază de cod, acum default-ul obișnuit.
- **Exactly-once nu este gratis.** Sink-urile tranzacționale adaugă latență și cost de throughput; multe echipe acceptă în schimb **at-least-once + upsert-uri idempotente** cheiate pe `txn_id`.
- **Date întârziate.** O plată care se decontează 2h mai târziu aterizează după închiderea ferestrei sale. Watermarks + allowed-lateness redeschid ferestrele, sau un job batch nocturn corectează numerele de ieri.
- **Multi-monedă / rambursări** trebuie modelate ca evenimente cu semn, altfel "venitul" derivează.
- **Când nu:** câteva mii de tranzacții/zi nu au nevoie de nimic din asta — o tabelă de rollup în Postgres actualizată de un cron bate un cluster Kafka+Flink pe care trebuie să-l operezi.

Arhitectură

Cum funcționează

Perspectiva de interviu

Compromisuri și eșecuri

Întrebări conexe