Write Ahead {B}Log

Este artigo nasce de uma palestra que tive a alegria de apresentar no AWSome Women Community Summit Brasil 2025, um evento que, em sua segunda edição, reuniu cerca de 500 mulheres em São Paulo para um dia intenso de troca, aprendizado e conexões reais. Foi um ambiente potente, diverso e inspirador, onde histórias, desafios e conquistas se encontraram e onde ficou ainda mais claro o quanto comunidades fortes transformam carreiras e a tecnologia como um todo.

Na minha palestra, compartilhei um pouco sobre sharding no MongoDB, explicando como essa estratégia de particionamento é fundamental para viabilizar escalabilidade horizontal em ambientes distribuídos, especialmente em sistemas modernos orientados a dados. Conversamos sobre benefícios, desafios reais de implementação, boas práticas e, principalmente, sobre como tomar decisões arquiteturais mais conscientes quando o volume de dados começa a crescer além do esperado.

Este texto é um convite para continuar aprendendo juntas, desmistificando conceitos que muitas vezes parecem complexos demais, mas que se tornam muito mais claros quando explicados com contexto, exemplos e experiências reais.

Vivemos a era do excesso de dados. Todos os dias, sistemas coletam eventos, cliques, transações, logs, sensores, mensagens e interações em uma velocidade que nunca existiu antes. O que antes era exceção (milhões de registros) hoje é apenas o começo. Em pouco tempo, falamos de dezenas de bilhões, depois terabyte e logo petabytes. Aqui nasce uma pergunta inevitável:

Como escalar dados sem quebrar sistemas, times e experiências de usuários?

Essa pergunta não é teórica. Ela aparece quando o dashboard começa a atrasar, quando uma API responde em segundos ao invés de milissegundos, quando um pico de acesso transforma uma aplicação estável em um gargalo constante. E, quase sempre, ela aparece tarde demais.

É exatamente nesse ponto que o Sharding no MongoDB deixa de ser um conceito avançado e passa a ser uma decisão estratégica.

Para entender o sharding, precisamos entender como um banco de dados normalmente cresce. Na maioria dos sistemas, o primeiro caminho é escalar verticalmente. Isso significa aumentar o tamanho da máquina onde o banco está rodando, colocando mais CPU, mais memória, mais disco.

No início, funciona bem. É simples, rápido e não exige grandes mudanças. O problema é que esse modelo tem um limite físico. Em algum momento, não existe uma máquina maior para comprar, ou o custo se torna inviável. É aí que surgem os gargalos, a latência aumenta e a experiência do usuário começa a ser impactada.

O sharding surge como uma resposta natural a esse limite. Em vez de concentrar todos os dados em um único servidor, o MongoDB permite dividir os dados entre vários servidores, distribuindo tanto o volume de informação quanto a carga de trabalho. Esse modelo é conhecido como escalabilidade horizontal. Em termos simples, ao invés de “crescer para cima”, o sistema cresce “para os lados”.

No MongoDB, um shard é, na prática, um replica set completo, ou seja, um conjunto de servidores que mantêm cópias sincronizadas dos mesmos dados. Dentro de um replica set, existe um nó primário responsável pelas escritas e um ou mais nós secundários que replicam esses dados continuamente. Essa arquitetura garante alta disponibilidade, pois, se o nó primário falhar, outro assume automaticamente, mantendo o banco acessível sem interrupção para a aplicação.

Um cluster sharded é composto por três elementos principais. Os shards são os servidores que armazenam os dados de fato, cada um contendo apenas uma parte do total. Os config servers funcionam como um mapa do cluster, guardando metadados que dizem onde cada pedaço de dado está localizado. Já o mongos atua como um roteador inteligente: é para ele que a aplicação se conecta, e é ele quem decide para qual shard cada consulta deve ser enviada. Tudo isso acontece de forma transparente para a aplicação, que não precisa saber onde os dados estão fisicamente.

O ponto central de todo esse mecanismo é a shard key, ou chave de fragmentação. Ela define como os dados serão distribuídos entre os shards. Sempre que um documento é inserido no MongoDB, o valor da shard key determina em qual shard aquele dado vai morar.

Por isso, a escolha dessa chave é uma das decisões mais importantes de toda a arquitetura. Uma shard key bem escolhida distribui os dados de forma equilibrada e permite que as consultas sejam rápidas. Uma escolha ruim pode concentrar dados e tráfego em poucos shards, criando os chamados hotspots.

Hotspots acontecem quando uma pequena parte do cluster recebe a maior parte das leituras e escritas, enquanto outros shards ficam subutilizados. Na prática, isso significa que alguns servidores ficam sobrecarregados, aumentando a latência e o risco de falhas, enquanto o restante da infraestrutura não é aproveitado, exatamente o oposto do que se espera de uma arquitetura distribuída.

No MongoDB, existem diferentes maneiras de dividir os dados entre os shards, e cada uma delas resolve um tipo específico de problema. Pensar nessas estratégias é como decidir como organizar um grande arquivo físico: a forma como você guarda as coisas muda completamente a facilidade de encontrá-las depois.

Uma das formas mais comuns é o sharding baseado em hash. Nesse modelo, o MongoDB pega o valor da shard key e aplica uma espécie de “embaralhamento” matemático antes de decidir em qual shard o dado será armazenado. O efeito prático disso é que os dados ficam espalhados de maneira muito equilibrada entre todos os shards. É como distribuir senhas aleatórias para filas de atendimento: cada fila recebe mais ou menos a mesma quantidade de pessoas, evitando sobrecarga em um único ponto.

Esse tipo de sharding é excelente para sistemas com muitas escritas e acessos distribuídos, porque reduz bastante o risco de hotspots. O lado negativo aparece quando precisamos fazer consultas por intervalo, como “todos os registros do último mês”. Como os dados estão espalhados de forma aleatória, o MongoDB precisa consultar vários shards ao mesmo tempo para responder, o que torna a operação mais pesada.

Outra estratégia é o sharding por intervalo, também chamado de range-based. Aqui, os dados não são embaralhados. Eles são organizados em faixas bem definidas, e cada shard fica responsável por um determinado intervalo de valores. Um exemplo simples é organizar dados por data: um shard guarda registros mais antigos, outro guarda registros mais recentes. Isso é parecido com dividir documentos por ano em pastas diferentes. Se você quer consultar tudo o que aconteceu em março, sabe exatamente em qual pasta procurar.

Esse modelo é muito eficiente para consultas ordenadas ou por período, mas exige atenção especial com dados novos. Se todos os registros recentes caírem sempre no mesmo shard, esse shard pode acabar recebendo quase toda a carga de escrita, se tornando um hotspot enquanto os outros ficam ociosos.

Existe também o zone-based sharding, que adiciona uma camada ainda mais estratégica à fragmentação dos dados. Nesse modelo, os dados são “marcados” com regras específicas que determinam em qual shard eles devem ficar. É como colocar etiquetas dizendo “este documento só pode ficar neste arquivo”.

Esse tipo de sharding é muito usado quando existem requisitos legais ou de negócio. Por exemplo, aplicações globais que precisam garantir que dados de usuários europeus fiquem armazenados apenas em data centers na Europa, por causa de leis como GDPR. Com zone sharding, é possível manter um único cluster MongoDB global, mas com dados fisicamente separados por região, sem que a aplicação precise lidar com essa complexidade.

O ponto mais importante é entender que não existe uma estratégia universalmente melhor. Cada forma de sharding favorece determinados tipos de acesso e dificulta outros. Por isso, escolher a estratégia certa não é apenas uma decisão técnica, mas uma decisão baseada no comportamento real da aplicação: como os dados são inseridos, como são consultados e quais respostas precisam ser mais rápidas.

Independentemente da estratégia escolhida, existe um conceito fundamental para entender o impacto do sharding na performance: queries direcionadas versus scatter-gather. Quando uma consulta utiliza a shard key de forma eficiente, o mongos consegue direcioná-la para um único shard. Isso é rápido e previsível. Já quando a consulta não usa a shard key, o sistema precisa consultar vários shards ao mesmo tempo e depois juntar os resultados. Esse tipo de operação é mais custosa e cresce em complexidade conforme o cluster aumenta. Por isso, um bom design de shard key sempre leva em conta quais são as consultas mais importantes do sistema e tenta otimizá-las ao máximo.

Outro ponto que costuma gerar receio é a ideia de que escolher uma shard key errada é um caminho sem volta. Durante muito tempo, isso foi verdade. Alterar a shard key significava criar uma nova coleção ou até um novo cluster, migrar dados e lidar com downtime.

Hoje, o MongoDB oferece o recurso de live resharding, que permite alterar a shard key em produção, sem interrupção da aplicação. Os dados são redistribuídos gradualmente, enquanto o sistema continua funcionando. Isso não elimina a necessidade de planejamento, mas reduz drasticamente o risco das decisões iniciais.

No fim, Sharding no MongoDB não é apenas uma técnica avançada de banco de dados. Ele é uma resposta direta a uma realidade incontornável: os dados vão continuar crescendo, independentemente de estarmos prontos ou não.

Arquiteturas que não consideram escalabilidade desde cedo acabam pagando um preço alto no futuro, seja em retrabalho, indisponibilidade ou experiência ruim para quem usa o sistema. Por outro lado, entender sharding, shard keys e distribuição de dados não significa complicar soluções, mas sim construir sistemas mais resilientes, preparados para crescer de forma saudável.