Quando NÃO usar Sharding: nem todo banco grande precisa ser quebrado em pedaços

Quando a gente começa a estudar System Design, é muito fácil cair na armadilha de achar que toda aplicação grande precisa de sharding.

Parece bonito falar:

“Vamos dividir os dados em vários shards para escalar horizontalmente.”

Mas na prática, sharding é uma daquelas decisões que podem resolver um problema grande… ou criar vários problemas novos antes mesmo de você precisar deles.

Então a pergunta mais importante talvez não seja:

“Como eu faço sharding?”

Mas sim:

“Quando eu NÃO deveria usar sharding?”

---

Primeiro: o que é sharding?

De forma simples, sharding é dividir os dados de um banco em partes menores, chamadas de shards.

Em vez de todos os dados ficarem em um único banco, eles são distribuídos entre vários bancos ou nós.

Exemplo:

Banco único:

users
- user_1
- user_2
- user_3
- user_4
- user_5

Com sharding:

Shard 1:
- user_1
- user_3
- user_5

Shard 2:
- user_2
- user_4

A ideia é reduzir a carga sobre uma única instância e permitir que o sistema escale horizontalmente.

Mas essa divisão não vem de graça.

---

1. Não use sharding se o seu problema é pequeno

Esse é o erro mais comum.

Às vezes a aplicação tem poucos usuários, pouco volume de escrita, pouco volume de leitura, mas a arquitetura já começa com:

• múltiplos bancos;
• roteamento por shard;
• estratégia de rebalanceamento;
• consistência distribuída;
• queries cross-shard;
• complexidade operacional.

Na maioria dos casos, isso é overengineering.

Antes de pensar em sharding, normalmente dá para resolver muita coisa com:

• índices melhores;
• queries otimizadas;
• cache;
• read replicas;
• particionamento;
• vertical scaling;
• ajuste de schema;
• filas para processamento assíncrono;
• revisão dos padrões de acesso.

Sharding deveria ser uma resposta para um gargalo real, não uma tentativa de parecer sofisticado.

---

2. Não use sharding se você ainda não conhece seus padrões de acesso

Sharding depende muito de uma boa escolha da shard key.

A shard key é o campo usado para decidir onde cada dado vai morar.

Exemplo:

user_id % 4

Ou:

region = "BR"
region = "US"
region = "EU"

O problema é que, se você ainda não entende como sua aplicação lê e escreve dados, provavelmente vai escolher uma shard key ruim.

E uma shard key ruim pode causar:

• hotspots;
• distribuição desigual;
• queries caras;
• dificuldade para rebalancear;
• aumento de latência;
• dependência forte de decisões difíceis de mudar depois.

Por exemplo, se você divide usuários por região, mas 90% dos usuários estão no Brasil, o shard do Brasil vai sofrer muito mais do que os outros.

Shard BR: 90% dos dados
Shard US: 5% dos dados
Shard EU: 5% dos dados

Nesse caso, você até “distribuiu” o banco, mas não distribuiu a carga de verdade.

---

3. Não use sharding se suas queries dependem muito de JOINs

Sharding combina melhor quando os dados acessados juntos ficam no mesmo shard.

Mas se seu sistema depende muito de queries como:

SELECT *
FROM orders
JOIN users ON users.id = orders.user_id
JOIN payments ON payments.order_id = orders.id
JOIN invoices ON invoices.order_id = orders.id;

Você precisa tomar cuidado.

Se users, orders, payments e invoices estiverem espalhados em shards diferentes, uma query que antes era simples pode virar uma operação distribuída.

E aí começam os problemas:

• mais latência;
• mais complexidade;
• mais chance de falha;
• maior dificuldade para manter consistência;
• queries que precisam consultar vários shards ao mesmo tempo.

Em banco relacional, JOIN já tem custo. JOIN distribuído tem mais custo ainda.

---

4. Não use sharding se transações fortes são essenciais

Imagine um sistema financeiro onde uma operação precisa:

1. debitar saldo de uma conta;
2. creditar saldo em outra conta;
3. registrar a transação;
4. atualizar o extrato;
5. garantir que tudo aconteceu junto.

Em um banco único, isso pode ser tratado com uma transação ACID tradicional.

Mas em um ambiente com shards diferentes, talvez a conta de origem esteja em um shard e a conta de destino em outro.

Shard 1:
- conta_origem

Shard 2:
- conta_destino

Agora você tem uma transação distribuída.

E transação distribuída é um problema bem mais complexo.

Você pode precisar lidar com:

• two-phase commit;
• rollback distribuído;
• inconsistência temporária;
• falhas parciais;
• idempotência;
• retry;
• eventos compensatórios.

Não significa que seja impossível, mas significa que você está pagando um preço alto.

Se o seu sistema precisa de consistência forte o tempo todo, sharding pode deixar tudo mais difícil.

---

5. Não use sharding se você ainda consegue escalar de formas mais simples

Antes de quebrar seu banco em shards, vale perguntar:

“Eu já esgotei as alternativas mais simples?”

Muitas vezes, não.

Você pode começar com:

Índices

Uma query lenta pode estar lenta simplesmente porque falta índice.

CREATE INDEX idx_orders_user_id ON orders(user_id);

Read replicas

Se o problema é muita leitura, talvez você não precise dividir os dados. Talvez precise só replicar leitura.

Primary DB  -> writes
Replica 1   -> reads
Replica 2   -> reads
Replica 3   -> reads

Cache

Se os mesmos dados são acessados o tempo todo, cache pode aliviar bastante o banco.

Exemplos:

• Redis;
• Memcached;
• CDN;
• cache na aplicação.

Particionamento

Às vezes você pode particionar tabelas dentro do próprio banco, sem precisar criar uma arquitetura distribuída manualmente.

Exemplo: particionar pedidos por data.

orders_2024
orders_2025
orders_2026

Isso pode resolver muita coisa antes de sharding entrar na conversa.

---

6. Não use sharding se sua equipe não está pronta para operar isso

Sharding não é só modelagem de dados.

É operação.

Você precisa pensar em:

• backup por shard;
• restore por shard;
• monitoramento;
• migração de dados;
• balanceamento;
• aumento de shards;
• falha parcial;
• deploy com múltiplos bancos;
• observabilidade;
• debugging distribuído.

Quando algo der errado, não vai ser simplesmente:

“O banco caiu.”

Pode ser:

“O shard 3 está com alta latência, mas só para usuários com IDs entre X e Y, e algumas queries cross-shard estão travando o serviço de pedidos.”

Isso exige maturidade técnica e operacional.

Se a equipe ainda está validando produto, MVP ou primeiras versões, sharding provavelmente vai mais atrapalhar do que ajudar.

---

7. Não use sharding só porque grandes empresas usam

Esse ponto é importante.

Empresas como Google, Meta, Amazon, Netflix e outras usam técnicas distribuídas pesadas porque elas têm problemas de escala gigantescos.

Mas a maioria dos sistemas não começa nesse nível.

Um SaaS pequeno ou médio pode rodar muito bem por bastante tempo com:

• PostgreSQL bem modelado;
• bons índices;
• cache;
• filas;
• read replicas;
• arquitetura modular;
• monitoramento decente.

Copiar arquitetura de Big Tech sem ter problema de Big Tech é uma forma rápida de criar complexidade desnecessária.

Arquitetura boa não é a mais complexa.

Arquitetura boa é a que resolve bem o problema atual e ainda deixa espaço para evoluir.

---

8. Não use sharding se você não tem uma estratégia de migração

Um problema sério do sharding é que ele é uma decisão difícil de desfazer.

Depois que os dados estão espalhados, qualquer mudança estrutural pode ficar mais complicada.

Você precisa pensar:

• como adicionar novos shards?
• como mover dados entre shards?
• como evitar downtime?
• como reprocessar dados?
• como mudar a shard key?
• como lidar com dados antigos?
• como manter consistência durante a migração?

Se você não tem resposta para essas perguntas, talvez ainda não seja hora de usar sharding.

---

Então quando sharding começa a fazer sentido?

Sharding começa a fazer sentido quando você tem sinais claros de que o banco único virou gargalo real.

Alguns sinais:

• volume de dados muito alto;
• muitas escritas concorrentes;
• uma única instância não suporta mais a carga;
• read replicas e cache já não resolvem;
• particionamento local não é suficiente;
• padrões de acesso são bem conhecidos;
• a shard key é relativamente clara;
• a equipe tem maturidade para operar ambiente distribuído.

Ou seja: sharding não deveria ser o primeiro passo.

Deveria ser uma etapa avançada de escala.

---

Uma forma simples de pensar

Antes de usar sharding, eu gosto de pensar nessa ordem:

1. Modelagem correta
2. Índices
3. Queries melhores
4. Cache
5. Filas
6. Read replicas
7. Particionamento
8. Vertical scaling
9. Sharding

Não é uma regra absoluta, mas ajuda a lembrar que sharding está mais perto do fim da jornada do que do começo.

---

Conclusão

Sharding é poderoso, mas também é caro.

Ele aumenta a capacidade de escala, mas cobra em complexidade.

Você ganha distribuição, mas perde simplicidade.

Você ganha capacidade horizontal, mas precisa lidar com roteamento, rebalanceamento, consistência, queries distribuídas e operação mais difícil.

Então, na maioria dos casos, a melhor decisão é:

Não use sharding cedo demais.

Primeiro entenda seus dados, seus acessos, seus gargalos e suas garantias de consistência.

Porque escalar um sistema é importante.

Mas escalar a complexidade antes da necessidade pode quebrar o projeto antes mesmo do banco quebrar.