Analytics de receita em tempo real sobre milhões de transações/dia: como?

Question

IT Interview Practice · Accepted Answer

**Faça streaming das transações através do Kafka para um stream processor que pré-agrega em um store OLAP, para que os dashboards leiam rollups minúsculos pré-computados em vez de escanear eventos crus.** Com milhões de txns/dia você nunca roda `SUM()` sobre a tabela crua a cada carregamento de página — você agrega uma vez, na escrita.

## Arquitetura

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

## Como funciona

- **Kafka** é o log durável. Cada pagamento publica um evento (`amount`, `currency`, `ts`, `merchant`). Ele bufferiza picos, desacopla produtores de consumidores e permite fazer **replay** do histórico para reconstruir agregados.
- **Stream processor (Flink / Kafka Streams)** mantém **janelas tumbling/sliding** (por minuto/hora) e agrega cada evento em um total acumulado em seu **state store**. A saída é uma linha pré-agregada por (minuto, dimensão).
- **Store OLAP (ClickHouse, Druid, Pinot)** armazena esses rollups de forma columnar. Um dashboard consultando "receita das últimas 24h" escaneia ~1.440 linhas, não milhões — sub-segundo.
- **Materialized views** no ClickHouse podem fazer o mesmo rollup dentro do DB (`AggregatingMergeTree`) se você quiser menos partes móveis.

## Perspectiva de entrevista

O entrevistador sonda se você **pré-agrega na escrita vs escaneia na leitura**, e se você entende **exactly-once**. Boas respostas nomeiam Kafka + OLAP; respostas excelentes explicam **por que eventos atrasados/duplicados corrompem os totais** e como corrigi-los: chaves idempotentes, **checkpointing + transactional sink** do Flink para exactly-once, e **watermarks** para fechar janelas apesar de chegadas atrasadas. Uma armadilha comum é propor um `SELECT SUM()` no Postgres — ok com milhares/dia, ele colapsa com milhões.

## Trade-offs e falhas

- **Lambda vs Kappa.** Lambda roda uma camada batch (Spark noturno reconcilia a fonte de verdade) ao lado da camada de stream (rápida mas aproximada) — preciso mas duas bases de código. **Kappa** usa apenas a camada de stream e **faz replay do Kafka** para corrigir bugs — mais simples, uma base de código, agora o padrão comum.
- **Exactly-once não é grátis.** Transactional sinks adicionam latência e custo de throughput; muitos times aceitam **at-least-once + upserts idempotentes** indexados por `txn_id` em vez disso.
- **Dados atrasados.** Um pagamento que liquida 2h atrasado chega depois que sua janela fechou. Watermarks + allowed-lateness reabrem janelas, ou um job batch noturno corrige os números de ontem.
- **Multi-moeda / reembolsos** devem ser modelados como eventos com sinal, senão a "receita" desvia.
- **Quando não usar:** alguns milhares de txns/dia não precisam de nada disso — uma tabela de rollup no Postgres atualizada por um cron supera um cluster Kafka+Flink que você tem que operar.

Arquitetura

Como funciona

Perspectiva de entrevista

Trade-offs e falhas

Perguntas relacionadas