Analytique de revenu en temps réel sur des millions de transactions/jour : comment ?

Question

IT Interview Practice · Accepted Answer

**Streamez les transactions à travers Kafka vers un stream processor qui pré-agrège dans un store OLAP, pour que les dashboards lisent de minuscules rollups pré-calculés au lieu de scanner les événements bruts.** À des millions de txns/jour, vous n'exécutez jamais un `SUM()` sur la table brute à chaque chargement de page — vous agrégez une fois, à l'écriture.

## Architecture

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

## Comment ça fonctionne

- **Kafka** est le log durable. Chaque paiement publie un événement (`amount`, `currency`, `ts`, `merchant`). Il bufferise les pics, découple les producteurs des consumers, et permet de **rejouer** l'historique pour reconstruire les agrégats.
- **Stream processor (Flink / Kafka Streams)** maintient des **fenêtres tumbling/sliding** (par minute/heure) et replie chaque événement dans un total courant dans son **state store**. La sortie est une ligne pré-agrégée par (minute, dimension).
- **Store OLAP (ClickHouse, Druid, Pinot)** stocke ces rollups en columnar. Un dashboard interrogeant « revenu des dernières 24h » scanne ~1 440 lignes, pas des millions — sous la seconde.
- **Vues matérialisées** dans ClickHouse peuvent faire le même rollup à l'intérieur de la DB (`AggregatingMergeTree`) si vous voulez moins de pièces mobiles.

## Perspective d'entretien

L'examinateur sonde si vous **pré-agrégez à l'écriture vs scannez à la lecture**, et si vous comprenez l'**exactly-once**. Les bonnes réponses nomment Kafka + OLAP ; les excellentes expliquent **pourquoi les événements tardifs/dupliqués corrompent les totaux** et comment les corriger : clés idempotentes, **checkpointing + sink transactionnel** de Flink pour l'exactly-once, et **watermarks** pour fermer les fenêtres malgré les arrivées tardives. Un piège courant est de proposer un `SELECT SUM()` sur Postgres — correct à des milliers/jour, il s'effondre à des millions.

## Compromis et pannes

- **Lambda vs Kappa.** Lambda fait tourner une couche batch (un Spark nocturne réconcilie la source de vérité) à côté de la couche stream (rapide mais approximative) — précis mais deux codebases. **Kappa** n'utilise que la couche stream et **rejoue Kafka** pour corriger les bugs — plus simple, une seule codebase, désormais le défaut courant.
- **L'exactly-once n'est pas gratuit.** Les sinks transactionnels ajoutent de la latence et un coût de throughput ; beaucoup d'équipes acceptent plutôt l'**at-least-once + upserts idempotents** indexés par `txn_id`.
- **Données tardives.** Un paiement se réglant 2h en retard arrive après la fermeture de sa fenêtre. Watermarks + allowed-lateness rouvrent les fenêtres, ou un job batch nocturne corrige les chiffres de la veille.
- **Multi-devise / remboursements** doivent être modélisés comme des événements signés, sinon le « revenu » dérive.
- **Quand ne pas le faire :** quelques milliers de txns/jour n'ont besoin de rien de tout cela — une table de rollup Postgres mise à jour par un cron bat un cluster Kafka+Flink que vous devez exploiter.

Architecture

Comment ça fonctionne

Perspective d'entretien

Compromis et pannes

Questions connexes