Desenhe um pipeline de tracking de eventos de alto volume para relatórios e ML — que stack?

Question

IT Interview Practice · Accepted Answer

A centenas de milhões de eventos/dia (~alguns milhares/seg, mais nos picos) a jogada vencedora é desacoplar a ingestão do serviço: absorver as escritas num log durável, processar o stream uma vez e distribuir para dois stores otimizados para tarefas opostas — pré-agregado para os pais (leituras rápidas), bruto e de fidelidade total para ML.

uma sala de correio — o coletor recebe o correio, o Kafka é a passadeira transportadora, e cada item é copiado para duas prateleiras: um que os pais consultam de relance, e um que a equipa de ML explora a fundo.

**Modelo mental:** uma sala de correio — o coletor recebe o correio, o Kafka é a passadeira transportadora, e cada item é copiado para duas prateleiras: um *quadro de resumo* que os pais consultam de relance, e um *arquivo completo* que a equipa de ML explora a fundo.

## Write path (ingest)

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

- **Coletor** recebe eventos em **batch** por HTTP — o batching no cliente transforma centenas de milhões de escritas minúsculas em muito menos pedidos.
- **Kafka** é o buffer durável: absorve picos, desacopla produtores de consumidores e permite **replay** do histórico quando o ML adiciona uma feature ou quando introduz um novo rollup.
- **Stream processor** lê o Kafka uma vez e escreve em ambos os sinks — anexa o bruto ao lake, faz upsert dos rollups para os relatórios.

```js
// Um consumidor lê o Kafka uma vez e escreve em AMBOS os sinks
for await (const batch of kafka.consume('events')) {
  await lake.appendParquet(batch);                      // bruto -> S3/Parquet (ML)
  for (const e of batch)
    rollup.add({ childId: e.childId, day: dayOf(e.ts) },// agrega -> OLAP (relatórios)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## Read path (serving)

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

Os pais atingem **resumos pré-agregados**, portanto um relatório é uma consulta por chave, nunca uma varredura sobre milhares de milhões de linhas. O ML consulta o **lake bruto**, mantendo cada campo para feature engineering.

## Stack & porquê
- **Kafka** — buffer, desacoplar, replay.
- **ClickHouse / tabelas de resumo diário** — otimizadas para leitura nos dashboards dos pais.
- **S3 + Parquet** — armazenamento bruto barato, colunar e flexível para ML.
- **Schema registry** — impõe o contrato de eventos para que os produtores não possam quebrar silenciosamente os consumidores.

## Perspetiva de entrevista
O entrevistador testa se separa a **ingestão otimizada para escrita do serviço otimizado para leitura**, se evita varrer eventos brutos a cada relatório de pai e se mantém os dados brutos para ML. **Fraco:** "meter tudo no Postgres e consultar." **Forte:** buffer durável + dois caminhos de serviço + replay + um contrato de schema, com sensibilidade à escala.

## Compromissos
A pré-agregação dá leituras instantâneas mas fixa as dimensões à partida; o lake bruto é flexível mas lento. Mantenha **ambos** — a clássica divisão write-once, read-many.

Write path (ingest)

Read path (serving)

Stack & porquê

Perspetiva de entrevista

Compromissos

Perguntas relacionadas