Analytics di fatturato in tempo reale su milioni di transazioni/giorno: come?

Question

IT Interview Practice · Accepted Answer

**Fai streaming delle transazioni attraverso Kafka verso uno stream processor che pre-aggrega in uno store OLAP, così che le dashboard leggano piccoli rollup pre-calcolati invece di fare scan degli eventi grezzi.** A milioni di transazioni/giorno non esegui mai `SUM()` sulla tabella grezza a ogni caricamento di pagina — aggreghi una sola volta, in scrittura.

## Architettura

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

## Come funziona

- **Kafka** è il log durevole. Ogni pagamento pubblica un evento (`amount`, `currency`, `ts`, `merchant`). Bufferizza i picchi, disaccoppia i producer dai consumer e ti permette di fare **replay** della storia per ricostruire gli aggregati.
- **Stream processor (Flink / Kafka Streams)** mantiene **tumbling/sliding window** (per minuto/ora) e ripiega ogni evento in un totale progressivo nel suo **state store**. L'output è una riga pre-aggregata per (minuto, dimensione).
- **Store OLAP (ClickHouse, Druid, Pinot)** memorizza quei rollup in modo columnar. Una dashboard che interroga "fatturato ultime 24h" fa scan di ~1.440 righe, non di milioni — sotto il secondo.
- **Materialized view** in ClickHouse possono fare lo stesso rollup dentro il DB (`AggregatingMergeTree`) se vuoi meno parti in movimento.

## Prospettiva del colloquio

L'intervistatore sonda se **pre-aggreghi in scrittura vs fai scan in lettura**, e se comprendi l'**exactly-once**. Le buone risposte nominano Kafka + OLAP; le eccellenti spiegano **perché gli eventi tardivi/duplicati corrompono i totali** e come correggerli: idempotency key, **checkpointing di Flink + transactional sink** per l'exactly-once, e **watermark** per chiudere le window nonostante gli arrivi tardivi. Una trappola comune è proporre `SELECT SUM()` su Postgres — va bene a migliaia/giorno, collassa a milioni.

## Compromessi e modalità di guasto

- **Lambda vs Kappa.** Lambda esegue un batch layer (uno Spark notturno riconcilia la fonte di verità) accanto allo stream layer (veloce ma approssimato) — accurato ma due codebase. **Kappa** usa solo lo stream layer e fa **replay di Kafka** per correggere i bug — più semplice, una sola codebase, ormai il default comune.
- **L'exactly-once non è gratis.** I transactional sink aggiungono latenza e costo di throughput; molti team accettano invece **at-least-once + upsert idempotenti** indicizzati per `txn_id`.
- **Dati tardivi.** Un pagamento che si settla con 2h di ritardo arriva dopo la chiusura della sua window. Watermark + allowed-lateness riaprono le window, oppure un job batch notturno corregge i numeri di ieri.
- **Multi-valuta / rimborsi** vanno modellati come eventi con segno, altrimenti il "fatturato" va alla deriva.
- **Quando non farlo:** poche migliaia di transazioni/giorno non richiedono nulla di tutto ciò — una tabella di rollup Postgres aggiornata da un cron batte un cluster Kafka+Flink che devi gestire.

Architettura

Come funziona

Prospettiva del colloquio

Compromessi e modalità di guasto

Domande correlate