Analítica de ingresos en tiempo real sobre millones de transacciones/día: ¿cómo?

Question

IT Interview Practice · Accepted Answer

**Transmite las transacciones a través de Kafka hacia un stream processor que pre-agregue en un store OLAP, de modo que los dashboards lean rollups diminutos pre-calculados en lugar de escanear eventos crudos.** Con millones de txns/día nunca ejecutas `SUM()` sobre la tabla cruda en cada carga de página — agregas una vez, al escribir.

## Arquitectura

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

## Cómo funciona

- **Kafka** es el log duradero. Cada pago publica un evento (`amount`, `currency`, `ts`, `merchant`). Bufferiza los picos, desacopla productores de consumidores, y te deja **replay** del historial para reconstruir agregados.
- **El stream processor (Flink / Kafka Streams)** mantiene **ventanas tumbling/sliding** (por minuto/hora) y pliega cada evento en un total acumulado en su **state store**. La salida es una fila pre-agregada por (minuto, dimensión).
- **El store OLAP (ClickHouse, Druid, Pinot)** almacena esos rollups de forma columnar. Un dashboard que consulta "ingresos últimas 24h" escanea ~1.440 filas, no millones — sub-segundo.
- **Las materialized views** en ClickHouse pueden hacer el mismo rollup dentro de la DB (`AggregatingMergeTree`) si quieres menos piezas móviles.

## Perspectiva de la entrevista

El entrevistador sondea si **pre-agregas al escribir vs escaneas al leer**, y si entiendes el **exactly-once**. Las buenas respuestas nombran Kafka + OLAP; las excelentes explican **por qué los eventos tardíos/duplicados corrompen los totales** y cómo arreglarlo: idempotency keys, **checkpointing + transactional sink** de Flink para exactly-once, y **watermarks** para cerrar ventanas a pesar de las llegadas tardías. Una trampa común es proponer `SELECT SUM()` en Postgres — bien a miles/día, colapsa a millones.

## Compensaciones y modos de fallo

- **Lambda vs Kappa.** Lambda corre una capa batch (un Spark nocturno reconcilia el source of truth) junto a la capa stream (rápida pero aproximada) — precisa pero dos codebases. **Kappa** usa solo la capa stream y **hace replay de Kafka** para arreglar bugs — más simple, un codebase, ahora el default común.
- **El exactly-once no es gratis.** Los transactional sinks añaden latencia y coste de throughput; muchos equipos aceptan **at-least-once + upserts idempotentes** con clave `txn_id` en su lugar.
- **Datos tardíos.** Un pago que liquida 2h tarde aterriza tras cerrarse su ventana. Los watermarks + allowed-lateness reabren ventanas, o un job batch nocturno corrige los números de ayer.
- **Multi-moneda / reembolsos** deben modelarse como eventos con signo, o los "ingresos" derivan.
- **Cuándo no:** unos pocos miles de txns/día no necesitan nada de esto — una tabla de rollup en Postgres actualizada por un cron le gana a un cluster de Kafka+Flink que tienes que operar.

Arquitectura

Cómo funciona

Perspectiva de la entrevista

Compensaciones y modos de fallo

Preguntas relacionadas