Replicação e sharding sem mistério

O problema

Esse assunto costuma ser mal explicado de um jeito bem previsível.

Alguém pergunta:

• “como você escalaria esse banco?”

E as respostas aparecem rápido:

• “coloca réplica”
• “faz sharding”

As duas soam sofisticadas.

As duas podem ser chute.

O problema é que replicação e sharding resolvem dores diferentes. Quando alguém trata as duas como se fossem etapas obrigatórias da mesma escada, normalmente está desenhando solução antes de dizer qual limite do sistema realmente apareceu.

Modelo mental

Guarda esta frase:

replicação copia o mesmo dado; sharding divide o dado.

Replicação normalmente entra para ajudar em:

• leitura
• disponibilidade
• failover

Sharding normalmente entra quando a dor já é:

• volume grande demais para um único nó
• escrita grande demais para um único nó
• limite estrutural de CPU, memória, disco ou throughput

Em português simples:

• réplica é mais gente lendo a mesma estante
• shard é dividir os livros em estantes diferentes

Isso já separa dois raciocínios que muita gente mistura.

Quebrando o problema

O que a replicação compra

No desenho mais comum, existe um primary que recebe escrita e uma ou mais réplicas que recebem a cópia desse estado depois.

Isso costuma ajudar em:

• distribuir leitura
• reduzir pressão no primary
• ter caminho de failover

Por isso réplica costuma ser a primeira resposta realista quando o sistema é muito mais lido do que escrito.

O que a replicação não compra

Réplica não multiplica a capacidade de escrita do primary.

Se o seu problema é:

• escrita concentrada
• lock demais
• disco no limite do nó principal

então você não resolveu a dor estrutural. Só tirou parte da leitura da frente.

Também existe o lag de replicação.

Ou seja:

• a escrita já entrou no primary
• a réplica ainda não refletiu aquele estado

Então replicação não é só performance. Também é decisão de consistência percebida.

Quando sharding entra na conversa

Sharding aparece quando um único nó para de escalar de forma saudável.

Agora o dado deixa de ser copiado inteiro para cada nó e passa a ser dividido.

Cada shard guarda só uma parte do conjunto total.

Isso ajuda a distribuir:

• armazenamento
• leitura
• escrita

Mas cobra complexidade em troca:

• roteamento de request
• join mais difícil
• transação entre shards mais cara
• rebalanço operacionalmente sensível

Então shard não é “versão avançada” de réplica.

Shard é outra categoria de decisão.

A sharding key é o centro do desenho

Não existe shard bom sem uma chave de particionamento que faça sentido.

A pergunta não é só “por qual campo dá para dividir?”.

É:

• esse campo distribui bem a carga?
• ele combina com o padrão principal de acesso?
• ele cria hot shard?

Exemplo ruim:

• particionar por country quando 80% da base está em um país só

Exemplo melhor:

• particionar por user_id quando a maioria das leituras e escritas gira em torno do usuário e o volume por usuário é relativamente distribuído

Resharding custa caro porque mexe no chão da casa

Esse é o ponto que muita resposta decorada ignora.

Se a chave foi mal escolhida, corrigir depois pode envolver:

• mover muito dado online
• reindexar
• mudar roteamento
• conviver com estado antigo e novo ao mesmo tempo

Em outras palavras: shard errado não é só um detalhe ruim de modelagem. É uma conta operacional pesada.

Exemplo simples

Imagina um produto com feed e perfil de usuário.

No começo, um banco só aguenta bem.

Depois de um tempo, a leitura explode:

• home do usuário
• lista de notificações
• tela administrativa

Mas a escrita ainda está sob controle.

Nesse momento, read replica costuma ser uma resposta boa porque a dor dominante é leitura.

Mais tarde, o produto cresce, cada usuário gera muito mais escrita, o volume total de dados sobe e o primary começa a virar gargalo estrutural.

A conversa muda.

Aí sharding passa a fazer sentido porque o problema deixou de ser “muita leitura no mesmo banco” e virou “um único nó já não segura bem o conjunto inteiro”.

Essa ordem importa.

Muita resposta ruim pula direto para shard por ansiedade de escala.

Erros comuns

• Falar “réplica” sem mencionar lag de replicação.
• Defender shard sem dizer qual chave distribui a carga.
• Usar réplica para um problema que era claramente de escrita.
• Tratar shard como coisa inevitável para qualquer sistema que cresce.
• Ignorar o custo de resharding e de operação diária.

Como um senior pensa

Quem tem mais experiência normalmente começa pela dor dominante, não pela ferramenta mais impressionante.

A pergunta útil é:

o limite real está em leitura, escrita, volume, disponibilidade ou crescimento operacional?

Se a dor principal é leitura e disponibilidade, replicação costuma ser candidata forte.

Se o problema já é limite estrutural de um nó só, aí shard entra.

Senioridade aparece aqui em não comprar complexidade antes da hora e em saber dizer claramente o que cada escolha melhora, o que ela não melhora e qual conta nova ela cria.

O que o entrevistador quer ver

Em entrevista, esse tema separa rápido resposta decorada de raciocínio real.

O avaliador quer ver se você:

• diferencia copiar dado de dividir dado
• entende que réplica traz lag e consistência percebida
• sabe que shard depende de chave bem escolhida
• evita complexidade distribuída antes de justificar o limite

Uma resposta forte costuma soar assim:

Se a dor principal é leitura e disponibilidade, eu considero replicação porque ainda estou lidando com o mesmo conjunto de dados. Se o problema já é limite estrutural de armazenamento ou escrita num único nó, aí sharding entra. E, antes de defender shard, eu preciso dizer qual chave distribui bem e qual custo estou comprando em operação e consistência.

Replicação compra fôlego. Sharding compra escala estrutural. Os dois custam.

O desenho bom é saber qual dor existe agora e qual conta vale a pena pagar.