Diseña un pipeline de tracking de eventos de alto volumen para informes y ML — ¿qué stack?

Question

IT Interview Practice · Accepted Answer

Con cientos de millones de eventos/día (~unos pocos miles/seg, más en los picos) la jugada ganadora es desacoplar la ingesta del serving: absorber las escrituras en un log durable, procesar el stream una sola vez, y distribuir a dos almacenes ajustados para trabajos opuestos — preagregado para los padres (lecturas rápidas), crudo y de fidelidad completa para ML.

una sala de correo — el collector recibe el correo, Kafka es la cinta transportadora, y cada elemento se copia en dos estanterías: un que los padres ojean, y un que el equipo de ML escudriña.

**Modelo mental:** una sala de correo — el collector recibe el correo, Kafka es la cinta transportadora, y cada elemento se copia en dos estanterías: un *tablero de resumen* que los padres ojean, y un *archivo completo* que el equipo de ML escudriña.

## Ruta de escritura (ingesta)

```text
Client ─(batch)─▶ Collector ─▶ Kafka ─▶ Stream proc ─┬─▶ OLAP rollup  (daily summaries)
 (learning app)    (HTTP)     (buffer,   (read once)  └─▶ S3 / Parquet (raw events)
                              replay)
```

- El **collector** recibe eventos **en lotes** sobre HTTP — hacer batching en el cliente convierte cientos de millones de escrituras diminutas en muchas menos peticiones.
- **Kafka** es el buffer durable: absorbe los picos, desacopla los productores de los consumidores, y te permite hacer **replay** del historial cuando ML añade una feature o introduces un nuevo rollup.
- El **stream processor** lee Kafka una vez y escribe en ambos sinks — anexa lo crudo al lake, hace upsert de los rollups para los informes.

```js
// Un consumer lee Kafka una vez y escribe en AMBOS sinks
for await (const batch of kafka.consume('events')) {
  await lake.appendParquet(batch);                      // crudo -> S3/Parquet (ML)
  for (const e of batch)
    rollup.add({ childId: e.childId, day: dayOf(e.ts) },// agregado -> OLAP (informes)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## Ruta de lectura (serving)

```text
Parent app ─▶ API ─▶ OLAP rollup                 (pre-aggregated: report = O(1), no scan)
ML / Data  ─▶ Spark / warehouse ─▶ S3 / Parquet  (raw, flexible, ad-hoc)
```

Los padres consultan **resúmenes preagregados**, así que un informe es una búsqueda por clave, nunca un escaneo sobre miles de millones de filas. ML consulta el **lake crudo**, conservando cada campo para el feature engineering.

## Stack y por qué
- **Kafka** — buffer, desacoplar, replay.
- **ClickHouse / tablas de resumen diario** — optimizadas para lectura en los dashboards de los padres.
- **S3 + Parquet** — almacenamiento crudo barato, columnar y flexible para ML.
- **Schema registry** — impone el contrato de eventos para que los productores no puedan romper silenciosamente a los consumidores.

## Enfoque de entrevista
El entrevistador sondea si separas la **ingesta optimizada para escritura del serving optimizado para lectura**, evitas escanear eventos crudos en cada informe de los padres, y conservas los datos crudos para ML. **Débil:** "mételo todo en Postgres y consúltalo". **Fuerte:** buffer durable + dos rutas de serving + replay + un contrato de schema, con un sentido de la escala.

## Trade-offs
La preagregación da lecturas instantáneas pero fija las dimensiones de antemano; el lake crudo es flexible pero lento. Conserva **ambos** — la clásica separación write-once, read-many.

Ruta de escritura (ingesta)

Ruta de lectura (serving)

Stack y por qué

Enfoque de entrevista

Trade-offs

Preguntas relacionadas