Como você faria sharding de um banco de dados para 1 bilhão de usuários?

Question

IT Interview Practice · Accepted Answer

Faça sharding por uma chave que esteja **presente em quase toda consulta e distribua a carga uniformemente** — geralmente um `user_id` hasheado — e depois planeje resharding e consultas cross-shard desde o primeiro dia. 1B de usuários não cabe nem tem performance em um único nó; você divide as linhas por vários bancos e roteia cada consulta para o shard que a possui.

```text
                 ┌──────────────┐
Request ─▶ Router/│ shard_of(key)│─▶ Shard 0  (users 0–…)
           Proxy  └──────────────┘   Shard 1
           (Vitess)      │           Shard 2
                         └─────────▶  Shard N   ← each = its own primary+replicas
Directory/lookup table (which key → which shard) ── for range or resharding
```

## Escolha da shard key — a decisão difícil de desfazer

Escolha uma chave com **alta cardinalidade, distribuição uniforme e presente na maioria das consultas**. `user_id` geralmente vence: consultas escopadas por usuário ("meu perfil, meus pedidos") batem em exatamente um shard. Uma chave ruim (ex. `country`) cria hotspots — um shard guarda toda a Índia enquanto outro fica ocioso.

## Hash vs range

- **Hash sharding** (`shard = hash(user_id) % N`): distribui uniformemente, mata hotspots — mas consultas de range ("usuários criados na semana passada") precisam fazer scatter-gather em todos os shards.
- **Range sharding** (`user_id 0–1M → shard 0`): mantém ranges locais e facilita o resharding, mas arrisca hotspots (os usuários mais novos todos caem no último shard).
- Resposta comum: **hash para carga uniforme**, com uma **tabela de lookup/directory** para que você possa mover ranges sem re-hashear tudo.

## Resharding — planeje antes de precisar

`% N` é uma armadilha: adicionar um shard remapeia quase toda chave. Use **consistent hashing** ou **virtual buckets** (mapeie chaves → 4096 buckets lógicos → shards físicos). Dividir um shard então move buckets, não todo o keyspace. Ferramentas como o **Vitess** (usado pelo YouTube/Slack) automatizam o resharding ao vivo com cutover.

## Consultas cross-shard

Qualquer coisa não indexada pela shard key é dolorosa: uma consulta global de "top posts" faz fan-out para todo shard e faz merge. Mitigue **desnormalizando** ou mantendo um índice/store de busca separado (Elasticsearch) para leituras transversais.

## Perspectiva de entrevista

Entrevistadores sondam se você entende que a escolha da shard key é **semi-permanente** e se você pensou em **resharding e joins cross-shard** — as duas coisas que mordem em produção. Bom: "fazer sharding por user_id." Excelente: você levanta consistent hashing, mitigação de shard quente e o fato de que transações distribuídas entre shards são melhor evitadas por completo.

**Armadilha comum:** `hash % N` com um N fixo — torna o crescimento futuro uma migração completa de dados.

## Trade-offs e modos de falha

- **Perda de ACID cross-shard:** sem joins/transações baratos entre shards; use sagas ou desnormalize.
- **Shard quente:** um usuário viral; faça sub-sharding ou cacheie essa entidade.
- **Risco de rebalanceamento:** a migração ao vivo deve fazer double-write e verificar antes do cutover.
- **Custo operacional:** N shards × réplicas = muitos bancos para monitorar, fazer backup e failover.

Escolha da shard key — a decisão difícil de desfazer

Hash vs range

Resharding — planeje antes de precisar

Consultas cross-shard

Perspectiva de entrevista

Trade-offs e modos de falha

Perguntas relacionadas