Como você consulta 10B de registros em menos de 100ms?

Question

IT Interview Practice · Accepted Answer

Projete primeiro para o **padrão de acesso**, depois escolha o particionamento + o índice/PK certo para que qualquer consulta única toque uma fatia pequena e limitada — nunca escaneie 10B de linhas. Menos de 100ms sobre 10 bilhões de registros não é sobre um disco mais rápido; é sobre tornar o working set minúsculo.

```text
Query ─▶ Router ──▶ Partition (by tenant/time) ──▶ Index/PK lookup ─▶ ~thousands of rows
   │                    (prune 99.9% of data)         (B-tree / sort key)
   └─▶ Cache (Redis) ─▶ hit? return in <5ms
                        miss ▼
                   Columnar store (ClickHouse) for aggregates / scans
```

## Padrões de acesso direcionam tudo

Antes de escolher a tecnologia, pergunte: **point lookup ou range/aggregate?** "Pegar os últimos 20 pedidos do usuário X" é uma consulta point/range — você quer que a partition e a sort key correspondam exatamente a ela. "Somar receita por região neste mês" é um scan analítico — um row store é a ferramenta errada. Modelar a consulta primeiro é o que separa um design que funciona de um que parece razoável mas faz full-scan.

## O particionamento reduz o espaço de busca

Divida a tabela por uma chave que apareça em toda consulta — geralmente **tenant_id + tempo**. Com partições de tempo, uma consulta por "últimos 7 dias" lê 7 partições e ignora os outros 3 anos. Isso é *partition pruning*: o router elimina 99,9% dos dados antes de qualquer índice ser consultado.

## Design correto de índice / PK

Dentro de uma partição, a **chave primária deve colocar as colunas de filtro da consulta na frente**. No DynamoDB: partition key = `tenant`, sort key = `timestamp` → consultas de range são O(log n) + leitura sequencial. Em um columnar store como o **ClickHouse**, a sorting key (`ORDER BY (tenant, ts)`) permite ao engine pular granules e ler apenas os blocos correspondentes. Um covering index evita a busca extra de linha por completo.

## Escolha do store

- **Point lookups, alta escrita:** NoSQL key-value (DynamoDB, Cassandra) — O(1)-ish por chave, escala horizontalmente.
- **Analytics/agregados:** columnar (ClickHouse, BigQuery) — lê apenas as colunas necessárias, vetorizado.
- **Cache do 1% quente:** Redis na frente absorve leituras repetidas em <5ms; 10B de linhas mas alguns milhões de chaves quentes.

## Perspectiva de entrevista

O entrevistador quer ver você dizer **"quais são as consultas?" antes de "qual banco de dados?"**. Bons candidatos recorrem a índices; os excelentes notam que um índice sobre 10B de linhas é ele próprio enorme — então você *particiona primeiro para reduzir o que o índice cobre*. Nomear a divisão row-vs-columnar e a camada de cache sinaliza experiência real com escala.

**Armadilha comum:** propor um único índice B-tree gigante como resposta. Ajuda em point lookups mas não faz nada para os scans analíticos, e suas escritas gargalam a ingestão.

## Trade-offs e modos de falha

- **Partition key errada** = scatter-gather entre partições, a latência dispara. Escolha uma chave presente nas consultas.
- **Partição quente:** um tenant celebridade sobrecarrega um shard — adicione um sufixo de salting.
- **Staleness de cache:** invalide na escrita ou aceite o atraso do TTL.
- **Custo de desnormalização:** você frequentemente duplica dados por padrão de acesso; armazenamento é barato, uma consulta de 10 segundos não é.

Padrões de acesso direcionam tudo

O particionamento reduz o espaço de busca

Design correto de índice / PK

Escolha do store

Perspectiva de entrevista

Trade-offs e modos de falha

Perguntas relacionadas