Como você armazena 100M de eventos de log por dia?

Question

IT Interview Practice · Accepted Answer

Construa um **pipeline append-only: agents → Kafka → armazenamento em camadas (quente no ClickHouse/ELK, frio em object storage)** com uma política de retenção que indexa dados recentes e arquiva o resto de forma barata. 100M de eventos/dia são ~1.200/seg em média (picos muito maiores) e dezenas a centenas de GB diários — você otimiza para escritas baratas e custo de consulta limitado, não para semântica OLTP.

```text
App/agents ─▶ Kafka ─▶ Consumers ─┬─▶ ClickHouse / ELK   (hot: last 7–30d, indexed, fast search)
 (Fluent Bit)  (buffer,            │
                replay)            └─▶ S3/Parquet         (cold: 90d–years, cheap, scan-on-demand)
                                          │
                                   Lifecycle/tiering ─▶ Glacier (archive) ─▶ delete at retention
```

## Pipeline de append

Logs são write-once, nunca atualizados — então o caminho de ingestão é um **append**. Agents como **Fluent Bit / Vector** enviam as linhas para o **Kafka**, que bufferiza rajadas e desacopla produtores do armazenamento. Se o ClickHouse estiver fora para manutenção, os eventos ficam na fila do Kafka e fazem replay — você não perde logs. Faça escritas em lote (milhares de linhas por insert) porque inserts por linha destroem o throughput em columnar stores.

## Store quente: indexar para busca

Logs recentes precisam de busca rápida ("erros na última hora do serviço X"). O **ClickHouse** (columnar, comprime 10x, escaneia bilhões de linhas/seg) ou a **stack ELK** (índice invertido do Elasticsearch) atendem isso. Particione por dia/serviço para que as consultas façam pruning para poucas partições. Essa camada é cara por GB, então mantenha-a pequena — apenas os últimos 7–30 dias.

## Store frio: object storage + tiering

Logs mais antigos migram para **S3 como Parquet** — barato, durável, consultável sob demanda via Athena/Trino. Uma **política de lifecycle** faz a transição S3 → Glacier → deleção no seu limite de retenção (ex. 1 ano). Esse *tiering* é a alavanca de custo central: armazenamento quente pode ser 50x o preço do de arquivamento.

## Perspectiva de entrevista

Entrevistadores sondam o **trade-off índice-vs-custo**: indexar tudo dá ótima busca mas estoura o orçamento; indexar nada é barato mas não consultável. Bom: "usar ELK." Excelente: você faz tiering — indexa a fatia quente recente, arquiva o resto no frio — e nomeia o Kafka como o buffer que torna a ingestão resiliente a indisponibilidades downstream.

**Armadilha comum:** colocar todos os logs no Elasticsearch para sempre. É a opção mais cara e seu cluster cai com a cardinalidade/retenção que você não planejou.

## Trade-offs e modos de falha

- **Retenção vs custo:** retenção mais longa = crescimento linear de armazenamento; faça tiering agressivamente.
- **Backpressure do Kafka:** se os consumidores atrasam, o disco enche — dimensione a retenção e monitore o lag.
- **Explosão de cardinalidade:** campos de alta cardinalidade (user_id) incham os índices do ES; faça amostragem ou descarte-os.
- **Custo de consulta em dados frios:** o Athena cobra por TB escaneado — particione o Parquet por data/serviço para que os scans fiquem limitados.
- **Duplicatas at-least-once:** faça dedup por um id de evento se contagens exatas importarem.

Pipeline de append

Store quente: indexar para busca

Store frio: object storage + tiering

Perspectiva de entrevista

Trade-offs e modos de falha

Perguntas relacionadas