Entendendo a Consistência do MongoDB: O Modelo BASE Explicado para Desenvolvedores

A consistência do MongoDB é confusa porque as pessoas a reduzem a uma frase: "O MongoDB é eventualmente consistente." Isso é muito vago para ser útil. Um conjunto de réplicas do MongoDB pode fornecer um comportamento forte para algumas operações e leituras desatualizadas para outras, dependendo do write concern, read concern, read preference e se uma falha está ocorrendo.

Se você está vindo do PostgreSQL ou MySQL, o maior ajuste é que a consistência não é uma configuração fixa para toda a aplicação. Você escolhe a garantia necessária para cada caminho. Um fluxo de checkout, um feed de notificações e um painel de análise não precisam todos da mesma atualização ou durabilidade.

ACID vs. BASE: Duas Abordagens para a Consistência

Antes de mergulhar no modelo do MongoDB, é útil entender os dois paradigmas principais para a consistência de banco de dados: ACID e BASE.

As Propriedades ACID (RDBMS Tradicional)

Os sistemas tradicionais de gerenciamento de banco de dados relacionais (RDBMS) como PostgreSQL ou MySQL geralmente aderem às propriedades ACID, garantindo a confiabilidade dos dados, especialmente em cargas de trabalho transacionais. ACID significa:

• Atomicidade: Cada transação é tratada como uma unidade única e indivisível. Ela é concluída inteiramente (commit) ou não acontece (rollback). Não há transações parciais.
• Consistência: Uma transação leva o banco de dados de um estado válido para outro. Garante que os dados gravados no banco de dados devem ser válidos de acordo com todas as regras e restrições definidas.
• Isolamento: Transações concorrentes são executadas em isolamento, parecendo ser executadas sequencialmente. O resultado de transações concorrentes é o mesmo que se fossem executadas uma após a outra.
• Durabilidade: Uma vez que uma transação foi confirmada (commit), ela permanecerá confirmada mesmo em caso de perda de energia, falhas ou outras falhas do sistema. As alterações são armazenadas permanentemente.

O ACID garante uma forte consistência, tornando-o ideal para aplicações que exigem estrita integridade de dados, como transações financeiras.

As Propriedades BASE (Bancos de Dados NoSQL como MongoDB)

Em contraste, muitos bancos de dados NoSQL, incluindo o MongoDB, priorizam a disponibilidade e a tolerância a partições em detrimento da consistência imediata, muitas vezes alinhando-se ao modelo BASE. BASE significa:

• Basicamente Disponível (Basically Available): O sistema garante disponibilidade, ou seja, responderá a qualquer solicitação, mesmo que não possa garantir a versão mais recente dos dados.
• Estado Flexível (Soft State): O estado do sistema pode mudar ao longo do tempo, mesmo sem entrada. Isso se deve ao modelo de consistência eventual, onde os dados se propagam pelo sistema de forma assíncrona.
• Consistência Eventual (Eventual Consistency): Se nenhuma nova atualização for feita em um determinado item de dados, eventualmente todos os acessos a esse item retornarão o último valor atualizado. Há um atraso antes que as alterações fiquem visíveis em todos os nós de um sistema distribuído.

Sistemas compatíveis com BASE são projetados para alta disponibilidade e escalabilidade em ambientes distribuídos, tornando-os adequados para aplicações que podem tolerar alguma latência na propagação de dados.

Entendendo a Consistência Eventual no MongoDB

O MongoDB pode apresentar um comportamento de consistência eventual quando as leituras são servidas a partir de secundários ou quando as gravações ainda não foram replicadas em todos os lugares. Isso significa que, quando você grava dados em um conjunto de réplicas do MongoDB, o nó primário reconhecerá a gravação e, em seguida, replicará assincronamente essa gravação para seus nós secundários. Enquanto o primário garante que a gravação seja durável, ele não espera que todos os secundários alcancem o estado antes de reconhecer o sucesso para o cliente. Consequentemente, uma leitura subsequente de um nó secundário pode não refletir imediatamente a gravação mais recente, embora se torne consistente eventualmente.

Esta escolha de design é fundamental para a capacidade do MongoDB de escalar horizontalmente e manter alta disponibilidade. Ao não exigir que todos os nós estejam perfeitamente sincronizados para cada operação, o MongoDB pode continuar a servir leituras e gravações mesmo que alguns nós estejam temporariamente indisponíveis ou atrasados.

As Compensações da Consistência Eventual

• Prós: Maior disponibilidade, melhor desempenho (menor latência para gravações) e maior escalabilidade para sistemas distribuídos.
• Contras: As aplicações devem ser projetadas para lidar com a possibilidade de ler dados desatualizados. Isso é particularmente relevante para operações onde a consistência imediata em todas as réplicas é crítica.

Read e Write Concerns do MongoDB: Ajustando a Consistência

Embora o MongoDB tenha como padrão a consistência eventual, ele fornece mecanismos poderosos – Read Concerns e Write Concerns – que permitem aos desenvolvedores ajustar o nível de consistência por operação. Isso permite que você equilibre consistência, disponibilidade e desempenho de acordo com as necessidades da sua aplicação.

Write Concerns

Um Write Concern descreve o nível de confirmação solicitado do MongoDB para uma operação de gravação. Ele dita quantos membros do conjunto de réplicas devem confirmar a gravação antes que a operação retorne sucesso.

Opções principais de Write Concern:

• w: Especifica o número de instâncias mongod que devem reconhecer a gravação.
  • w: 0: Nenhuma confirmação. O cliente não espera por nenhuma resposta do banco de dados. Isso oferece a maior taxa de transferência, mas corre o risco de perda de dados se o primário falhar imediatamente após a gravação.
  • w: 1 (Padrão): Confirmação apenas do nó primário. O primário confirma que recebeu e processou a gravação. É rápido, mas não garante que a gravação foi replicada para qualquer secundário.
  • w: "majority": Confirmação da maioria dos membros do conjunto de réplicas (incluindo o primário). Isso fornece garantias de durabilidade mais fortes, pois a gravação é confirmada em uma maioria de nós. Se o primário falhar, os dados têm garantia de existir em uma maioria de outros nós.
• j: Especifica se a instância mongod deve gravar no diário em disco antes de reconhecer a gravação. Ativar o diário (j: true) fornece durabilidade mesmo se o processo mongod falhar.
• wtimeout: Um limite de tempo para o write concern ser atendido. Se o write concern não for atendido dentro deste tempo, a operação de gravação retorna um erro.

Exemplo de Write Concern (usando w: "majority" com diário):

db.products.insertOne(
  { item: "laptop", qty: 50 },
  { writeConcern: { w: "majority", j: true, wtimeout: 5000 } }
);

Dica: Para dados críticos que devem ser duráveis e altamente disponíveis, w: "majority" com j: true é recomendado. Para dados menos críticos ou registro de alto rendimento, w: 1 ou mesmo w: 0 podem ser aceitáveis.

Read Concerns

Um Read Concern permite que você especifique o nível de consistência e isolamento para operações de leitura. Ele determina quais dados o MongoDB retorna para suas consultas, especialmente em um ambiente replicado.

Opções principais de Read Concern:

• local: Retorna dados da instância (primária ou secundária) à qual o cliente está conectado. Este é o padrão para instâncias independentes e secundários. Para conjuntos de réplicas, isso oferece a menor latência, mas pode retornar dados desatualizados.
• available: Retorna dados da instância sem garantir que os dados foram gravados em uma maioria do conjunto de réplicas. Semelhante a local, prioriza disponibilidade e baixa latência.
• majority: Retorna dados que foram confirmados por uma maioria dos membros do conjunto de réplicas. Isso garante que os dados são duráveis e não serão revertidos. Oferece consistência mais forte do que local ou available ao custo de latência potencialmente maior.
• linearizable: Garante que os dados retornados refletem a gravação confirmada mais recente globalmente. Este é o read concern mais forte, garantindo que as leituras vejam todas as gravações que foram confirmadas por um write concern de majority. Pode incorrer em sobrecarga de desempenho significativa e está disponível apenas para leituras do primário.
• snapshot (para transações de múltiplos documentos): Garante que a consulta retorna dados de um ponto específico no tempo, permitindo que as leituras sejam consistentes em vários documentos dentro de uma transação.

Exemplo de Read Concern (usando majority):

db.products.find(
  { item: "laptop" },
  { readConcern: { level: "majority" } }
);

Aviso: Embora linearizable forneça consistência forte, ele vem com implicações de desempenho. Use-o criteriosamente para cenários onde a ordenação estrita e a visibilidade global das gravações são críticas.

Por que BASE e Consistência Eventual Importam para a Escalabilidade

O modelo BASE e a consistência eventual são facilitadores principais para a escalabilidade e alta disponibilidade do MongoDB:

1. Escalabilidade Horizontal (Sharding): Ao relaxar a consistência imediata, o MongoDB pode distribuir dados por vários shards (clusters de conjuntos de réplicas). Cada shard opera de forma relativamente independente, permitindo que o banco de dados escale horizontalmente para lidar com conjuntos de dados massivos e alto rendimento, sem exigir que todos os nós em todo o sistema distribuído estejam perfeitamente sincronizados o tempo todo.
2. Alta Disponibilidade e Tolerância a Falhas: Em um conjunto de réplicas, se o nó primário ficar indisponível, um novo primário pode ser eleito a partir dos secundários. A consistência eventual significa que, mesmo durante falhas, os nós secundários podem continuar a servir leituras (dependendo do read concern), e o sistema permanece disponível. Se o primário tivesse que esperar por todos os secundários para cada gravação, um único secundário atrasado poderia engarrafar todo o sistema.
3. Desempenho: Requisitos de consistência menos rigorosos significam menor latência para operações de gravação e maior rendimento geral, pois o sistema não precisa bloquear e esperar por confirmações de todos os nós antes de prosseguir.

Ao oferecer consistência ajustável por meio de read e write concerns, o MongoDB capacita os desenvolvedores a tomar decisões informadas. Aplicações que priorizam alta disponibilidade e rendimento (por exemplo, ingestão de dados IoT, análises em tempo real) podem optar por consistência mais fraca. Por outro lado, aplicações que exigem integridade de dados mais forte (por exemplo, transações financeiras, atualizações de inventário) podem escolher níveis de consistência mais fortes, aceitando as compensações de desempenho associadas.

Considerações Práticas e Melhores Práticas

• Identifique Dados Críticos: Determine quais dados absolutamente exigem consistência forte (por exemplo, saldos de contas) versus dados que podem tolerar consistência eventual (por exemplo, atualizações de perfil de usuário, dados de sessão).
• Projete para Idempotência: Ao usar write concerns mais fracos, é possível que uma gravação tenha sucesso no primário, mas falhe antes da replicação para os secundários, levando a uma reversão subsequente e o cliente acreditando que a gravação falhou. Se o cliente tentar novamente a operação, isso pode resultar em duplicatas. Projete suas operações para serem idempotentes sempre que possível.
• Leia-Seus-Próprios-escritos do Lado do Cliente: Se um usuário realiza uma gravação e imediatamente tenta lê-la, ele pode ver dados desatualizados se estiver lendo de um secundário com um read concern fraco. Para garantir que um usuário sempre leia suas próprias gravações recentes, considere direcionar tais leituras para o primário ou usar um read concern majority, possivelmente combinado com um write concern majority para essas operações específicas.
• Monitoramento: Fique de olho no atraso do conjunto de réplicas usando rs.printReplicationInfo() ou métricas do MongoDB Atlas. Um alto atraso de replicação pode exacerbar os problemas de consistência eventual.

Uma Maneira Mais Útil de Pensar Sobre a Consistência do MongoDB

O MongoDB não é simplesmente "eventualmente consistente" em todas as situações, e tratá-lo dessa forma leva a designs desleixados. Uma leitura do primário após uma gravação confirmada pode se comportar de forma muito diferente de uma leitura roteada para um secundário que está alguns segundos atrasado. Uma gravação confirmada com w: 1 tem um perfil de risco diferente de uma gravação confirmada com w: "majority". A história da consistência depende da sua read preference, read concern, write concern, topologia e se uma falha acontece no momento errado.

Para uma página de produto normal, a consistência eventual pode ser suficiente. Se um administrador altera a descrição de um produto e um cliente vê a descrição antiga por um curto período de um secundário, o impacto nos negócios geralmente é pequeno. Para uma página de confirmação de pedido, a tolerância é diferente. Se um cliente envia um pedido e a próxima tela não consegue encontrá-lo, mesmo que brevemente, o sistema parece quebrado. É aí que o comportamento de ler-seus-próprios-escritos importa mais do que o rendimento bruto.

Um padrão prático é usar configurações mais fortes para caminhos de confirmação voltados ao usuário e configurações mais flexíveis para caminhos de segundo plano ou analíticos. Por exemplo, uma gravação de pedido pode usar w: "majority", e a leitura de confirmação imediata pode ir para o primário. Um painel que agrega a atividade de ontem pode ler de secundários porque um pequeno atraso geralmente é aceitável. Um pipeline de ingestão de logs pode aceitar uma confirmação mais fraca do que um livro-razão de faturamento, mas ainda deve ser honesto sobre o que pode ser perdido durante uma falha ou failover.

Tenha cuidado com a palavra "disponível" também. Um banco de dados distribuído pode continuar servindo algumas solicitações durante falhas, mas isso não significa que toda solicitação pode ter sucesso com as mesmas garantias. Uma eleição de primário pausa as gravações por um curto período. Um secundário pode servir leituras apenas se sua read preference permitir. Uma partição de rede pode forçar o MongoDB a escolher a segurança em vez de aceitar gravações em um nó que não pertence mais à maioria. Estas não são falhas; são as compensações que impedem que os dados replicados se dividam em duas histórias conflitantes.

Aqui está a decisão que eu escreveria em uma nota de design de aplicação:

Mutações críticas de conta, pedido e inventário:
- writeConcern: majority
- ler de volta do primário ao confirmar a própria ação do usuário
- usar gravações repetíveis onde o driver as suporta
- tornar as operações de gravação idempotentes com IDs de solicitação ou chaves únicas

Páginas de pesquisa, páginas de feed, análises e exibição de perfil não crítico:
- leituras secundárias podem ser aceitáveis
- tolerar resultados desatualizados na interface do usuário
- mostrar carimbos de data/hora quando a atualização for importante

Esse tipo de nota é mais útil do que dizer "MongoDB é BASE" e seguir em frente. Ela informa aos futuros engenheiros onde leituras desatualizadas são aceitáveis e onde não são.