Explicando Consistência Eventual para um Desenvolvedor de Banco de Dados Relacional

Em um sistema distribuído, os mesmos dados lógicos podem existir em várias máquinas, ou um serviço pode manter uma visão local de dados pertencentes a outro serviço. Consistência eventual significa que uma atualização não precisa atingir todas as cópias antes que o sistema a aceite. Por um tempo, leitores diferentes podem ver valores diferentes. Se as atualizações pararem e a comunicação e a replicação continuarem com sucesso, as cópias convergirão para o mesmo valor. "Eventual" por si só não promete um prazo específico.

Imagine vários ramos de uma biblioteca mantendo cópias de seu catálogo. Com consistência forte, assim que um bibliotecário altera a localização de um livro e recebe confirmação, qualquer consulta subsequente ao catálogo deve refletir essa alteração ou uma mais recente. Os ramos se coordenam para não responderem com uma localização desatualizada; se não conseguirem estabelecer o valor atual, podem ter que esperar ou retornar um erro.

Com consistência eventual, um ramo pode registrar a alteração e notificar os outros depois. Alguém em outro ramo pode ver brevemente a localização antiga na prateleira. Esse ramo não está necessariamente com defeito: ele está respondendo a partir de uma cópia local que ainda não foi atualizada. Essa é a principal mudança em relação ao seu fluxo de trabalho familiar do SQL: uma gravação bem-sucedida não significa necessariamente que todos os lugares de onde você pode ler já a refletem.

Há uma distinção terminológica importante. O C em ACID significa que as transações preservam invariantes do banco de dados, como restrições; a consistência forte entre réplicas geralmente se refere à linearizabilidade, onde as operações se comportam como se houvesse uma única cópia atualizada. Essas não são a mesma garantia. Um banco de dados pode executar transações ACID localmente enquanto replica assincronamente seus resultados em outros lugares. Além disso, o que uma consulta relacional vê depende de seu nível de isolamento de transação e snapshot.

Por que aceitar leituras desatualizadas? A coordenação custa tempo e torna as operações dependentes da comunicação entre máquinas. Entre regiões, os idas e vindas da rede podem ser substanciais. A replicação assíncrona permite leituras locais e, em alguns projetos, gravações locais sem esperar por réplicas distantes, melhorando a latência e reduzindo a dependência de outros nós.

O teorema CAP aprofunda esse trade-off durante uma partição de rede: quando grupos de nós não conseguem se comunicar, um sistema distribuído não pode garantir consistência linearizável e disponibilidade para todas as solicitações a um nó em funcionamento. Para preservar a consistência, ele deve, às vezes, atrasar ou rejeitar operações. Para continuar atendendo a solicitações em ambos os lados, ele deve, às vezes, permitir respostas ou atualizações que ainda não podem ser reconciliadas com o outro lado. A consistência eventual é uma abordagem comum para sistemas que escolhem disponibilidade nessa situação. CAP não significa "sempre escolha quaisquer dois"; a escolha inevitável surge durante as partições. Atualizações concorrentes também precisam de uma regra explícita de resolução de conflitos — a convergência não é mágica.

A contagem de curtidas de um aplicativo social é um bom candidato. Ver 120 curtidas brevemente em vez de 121 geralmente é inofensivo. Em contraste, a consistência eventual sozinha é inaceitável para impor a regra de não-cheque especial de uma conta bancária: dois serviços lendo o mesmo saldo desatualizado podem ambos autorizar saques. Essa decisão precisa de uma verificação e atualização atômica autoritativa ou coordenação equivalente. Mesmo dentro dessa aplicação bancária, um painel de análise pode ficar seguro atrás do tempo.

Dois padrões ajudam os usuários a lidar com o atraso. Primeiro, use UI otimista com comportamento de leitura-suas-gravações: mostre imediatamente o novo comentário de um usuário e mantenha-o visível enquanto as réplicas se atualizam, ou direcione as leituras desse usuário para uma fonte que aplicou sua gravação. Marque as alterações não confirmadas como pendentes e lide claramente com falhas em vez de tratá-las silenciosamente como salvas.

Segundo, torne o processamento assíncrono explícito. Mostre "Sua alteração foi salva; os resultados da pesquisa estão sendo atualizados", em seguida, pesquise ou use notificações push até que a visão de leitura relevante reflita a atualização. Distinguir os estados aceito, em processamento e concluído transforma uma tela aparentemente incorreta em um fluxo de trabalho compreensível.

Do "O banco de dados está sempre certo" para "O banco de dados estará certo em breve"

Quando você escreve SQL em um único banco de dados relacional, você vive dentro de uma garantia muito confortável. Você BEGIN, você UPDATE, você COMMIT, e a partir desse instante, todas as conexões do mundo veem o novo valor. Não há uma janela na qual um usuário vê a linha antiga e outro vê a nova. Essa garantia é o "C" e o "I" do ACID — consistência e isolamento — aplicados por bloqueios, travas e um único log de gravação antecipada em uma máquina.

Sistemas distribuídos quebram esse conforto, não por falta de cuidado, mas porque a física das redes força uma escolha. Entender essa escolha é o cerne da consistência eventual.

1. Consistência Forte vs. Eventual: A Analogia

Consistência forte é um único quadro branco em uma única sala.

Imagine que sua equipe mantém sua escala de plantão em um quadro branco físico em um único escritório. Se você quiser mudar quem está de plantão, você entra na sala e, enquanto está apagando e reescrevendo, ninguém mais pode ler — eles esperam na porta. No momento em que você se afasta, todos que entram veem exatamente a mesma programação correta. Existe apenas uma cópia da verdade, e o acesso a ela é serializado. Essa é a sua instância Postgres com um bloqueio de linha.

Consistência eventual é um boato se espalhando por uma empresa.

Agora imagine que sua empresa tem escritórios em Berlim, São Paulo e Singapura, e cada escritório mantém sua própria cópia da programação em seu próprio quadro branco. Você muda o quadro de Berlim. Um mensageiro é enviado para São Paulo e Singapura. Pelos próximos segundos — ou minutos, se o mensageiro pegar trânsito — um colega em Singapura lendo seu quadro local obtém a programação antiga. Eles não estão lendo dados corrompidos; eles estão lendo dados que estavam corretos até um momento atrás. Sem mais alterações, todos os três quadros convergirão para o mesmo valor. Essa garantia de convergência — "se as gravações pararem, todas as réplicas concordarão" — é precisamente o que "eventual" significa.

A mudança mental chave: obsoleto não é o mesmo que errado. Dados obsoletos são um estado passado válido do sistema. Dados corrompidos são um estado que o sistema nunca teve. A consistência eventual permite o primeiro e ainda proíbe o segundo.

2. Por Que Sistemas Distribuídos Escolhem Isso: O Trade-off CAP

O teorema CAP (teorema de Brewer) diz que um armazenamento de dados distribuído pode oferecer no máximo duas de três propriedades simultaneamente:

• C — Consistência: toda leitura retorna a escrita mais recente.
• A — Disponibilidade: toda solicitação recebe uma resposta sem erro.
• P — Tolerância a Partições: o sistema continua funcionando quando a rede falha ou atrasa mensagens entre nós.

Aqui está a parte que confunde as pessoas: P não é opcional. No momento em que seus dados residem em mais de uma máquina, partições de rede acontecerão — um switch falha, um cabo é cortado, uma zona de disponibilidade na nuvem se torna inacessível, uma pausa de GC faz um nó parecer morto. Você não pode "escolher" não ter partições mais do que pode escolher não ter gravidade. Portanto, CAP é realmente uma pergunta forçada: quando uma partição ocorre, você sacrifica C ou A?

• Escolha CP (sacrifica disponibilidade): Durante uma partição, nós que não conseguem confirmar que têm os dados mais recentes se recusam a responder. Leituras e gravações retornam erros ou bloqueiam até que a partição se cure. Seus dados nunca ficam obsoletos, mas seu serviço fica indisponível para alguns usuários. Isso é aproximadamente o que um sistema distribuído usando consenso (Raft/Paxos — pense em etcd, ZooKeeper ou um cluster SQL replicado sincronicamente) faz.

• Escolha AP (sacrifica consistência forte): Durante uma partição, cada nó continua respondendo com os melhores dados que tem localmente e reconcilia mais tarde quando a conectividade retorna. Ninguém vê um erro; algumas pessoas veem valores obsoletos por um tempo. Esse é o DynamoDB em seu modo padrão, Cassandra com configurações de quorum baixas, DNS e a maioria dos caminhos de leitura com backup de CDN.

Existem duas pressões adicionais além das partições:

Latência. Consistência forte entre geografias requer coordenação, e coordenação custa uma viagem de ida e volta na rede. Se uma gravação em Frankfurt deve ser confirmada por uma réplica em Sydney antes de você retornar 200 OK, você adicionou cerca de 250 ms de imposto de velocidade da luz a cada solicitação. Isso não é um bug que você pode otimizar; é o diâmetro do planeta. A extensão PACELC para CAP captura isso: se Particionado, escolha Disponibilidade ou Consistência; Caso contrário, escolha Latência ou Consistência. Mesmo em uma rede perfeitamente saudável, você ainda está pagando pela coordenação.

Acoplamento em microsserviços. Em seu monólito, a tabela de pedidos e a tabela de inventário estavam no mesmo banco de dados, então BEGIN TRANSACTION cobria ambos. Uma vez que Pedidos e Inventário são serviços separados com lojas separadas, uma única transação ACID entre eles requer um commit de duas fases — que mantém bloqueios em uma rede, e onde uma falha do coordenador pode deixar os participantes bloqueados indefinidamente. A maioria das equipes rejeita 2PC e, em vez disso, usa padrões assíncronos (publicação de eventos, o padrão outbox, sagas), e esses padrões são eventualmente consistentes por construção. A consistência eventual muitas vezes não é uma escolha de banco de dados; é a consequência inevitável de decompor seu sistema em serviços implantáveis independentemente.

Portanto, o resumo honesto é: sistemas distribuídos escolhem consistência eventual porque ela oferece disponibilidade durante falhas, baixa latência em escala e independência entre serviços — e porque para uma grande classe de dados, algumas centenas de milissegundos de obsolescência não têm custo de negócio.

3. Onde é Aceitável, e Onde Absolutamente Não É

Aceitável: um contador de "curtidas" ou visualizações em uma postagem social, ou um índice de busca.

Digamos que uma postagem tenha 4.812 curtidas. Você curte; a gravação vai para uma réplica local e retorna instantaneamente. Outro usuário em uma região diferente atualiza e vê 4.812 por mais 800 ms antes de ver 4.813. Qual o dano? Nada. Nenhum dinheiro foi movido, nenhuma promessa foi quebrada, nenhuma decisão foi tomada com base no número obsoleto. O mesmo vale para índices de busca (um artigo recém-publicado levando dois segundos para se tornar pesquisável), avatares de perfil de usuário, feeds de recomendação e painéis de análise. Em troca desse atraso inofensivo, o recurso permanece ativo durante uma partição de rede e responde em milissegundos de um dígito em todo o mundo.

O teste útil: pergunte o que quebra se um usuário agir com base em dados que têm 5 segundos de idade. Para um contador de curtidas, nada quebra.

Inaceitável: o lado do débito de uma transferência financeira, ou o inventário de um item escasso.

Considere mover € 500 entre duas contas, ou uma verificação de saldo de conta antes de um saque. Se a réplica do saldo estiver obsoleta, dois saques de ATM de € 500 contra um saldo de € 600 podem ser aprovados, e você criou € 400 do nada. Reconciliar isso "depois" significa que um cliente real deve dinheiro real, e possivelmente um problema regulatório. O mesmo se aplica à venda da última unidade de ingressos para shows, alocação de nomes de usuário exclusivos ou imposição de uma regra de "um voto por pessoa". Todas essas são restrições de unicidade ou de invariante não negativa, e invariantes que devem ser mantidos no instante da decisão não podem ser impostos por um sistema que só promete acordo depois.

Para esses casos, você precisa de consistência forte no caminho crítico: uma transação de partição única, um armazenamento com suporte a consenso, gravações condicionais/compare-and-set, ou um bloqueio ou concessão distribuída com escopo restrito em torno do invariante.

A nuance importante: esta não é uma decisão para toda a aplicação. No mesmo sistema de e-commerce, a autorização de pagamento do checkout é fortemente consistente, enquanto o carrossel "clientes também compraram", a contagem de avaliações de produtos e a lista de histórico de pedidos são eventualmente consistentes. Designs maduros escolhem a consistência por operação, pagando o custo de coordenação apenas onde um invariante genuinamente o exige. Uma saída comum é projetar o invariante para fora: em vez de "reservar o último ingresso atomicamente", modele um livro-razão de eventos de reserva somente de adição e compense com uma saga se você vender demais — que é exatamente como as companhias aéreas sempre lidaram com overbooking.

4. Dois Padrões para Ocultar o Atraso dos Usuários

Os usuários não têm um modelo mental de atraso de replicação. Se eles clicam em "Salvar", veem uma mensagem de sucesso, navegam para uma lista e a alteração deles não está lá, eles concluirão que seu produto está quebrado e clicarão em Salvar novamente — criando um duplicado. Dois padrões resolvem a maior parte disso.

Padrão A: Leia-suas-próprias-gravações (consistência de sessão), via UI otimista ou leituras fixas.

A falha mais chocante é um usuário não ver sua própria alteração. A correção é garantir a consistência apenas para a sessão do próprio usuário, o que é muito mais barato do que a consistência forte global. Duas implementações:

• UI otimista: o cliente renderiza imediatamente o resultado esperado da carga útil que acabou de enviar, em vez de esperar para reler do servidor. Quando você posta um comentário, o comentário aparece no tópico instantaneamente, renderizado do estado local, enquanto a gravação se propaga em segundo plano. Se o servidor finalmente rejeitá-lo, o cliente reverte o item e exibe um erro. É isso que faz com que aplicativos de chat e Google Docs pareçam instantâneos, apesar de serem altamente assíncronos.
• Leituras fixas / fixadas: após uma gravação, direcione as leituras desse usuário para o primário (ou para a réplica que aceitou a gravação) por uma curta janela, ou passe um token de versão — um token de consistência "leia-suas-gravações", LSN ou relógio vetorial — com leituras subsequentes para que o sistema possa esperar até que a réplica tenha alcançado pelo menos essa versão. O custo é pago apenas pela pequena fração de sessões que acabaram de gravar.

Padrão B: Estado explícito "pendente" no modelo de domínio e na UI.

Em vez de fingir que uma operação é instantânea, torne a etapa assíncrona uma parte de primeira classe do seu modelo de dados e da sua interface. Uma transferência bancária mostra como "Pendente — será concluída até amanhã"; um upload de vídeo mostra "Processando"; um pedido mostra "Pagamento confirmado, aguardando processamento." Isso é honesto, corresponde às expectativas do mundo real dos usuários (todos entendem que um cheque leva tempo para ser compensado) e converte uma ausência confusa de dados em informações significativas. Tecnicamente, essa é a mesma ideia de uma máquina de estados sobre o ciclo de vida de uma entidade, impulsionada por eventos de domínio, e se acopla naturalmente a uma saga: cada estágio transiciona o status visível, e uma falha o transiciona para um estado de compensação como "Reembolsado" em vez de desaparecer silenciosamente.

Duas práticas de suporte que valem a pena internalizar:

• Torne toda gravação idempotente. Anexe uma chave de idempotência gerada pelo cliente a cada solicitação. Se um usuário clicar duas vezes porque a UI atrasou, ou uma nova tentativa for disparada após um tempo limite, a segunda solicitação é reconhecida e descartada em vez de criar um segundo pedido. Em um mundo eventualmente consistente, a entrega "exatamente uma vez" é uma ficção; manipuladores idempotentes são como obtemos efeitos "exatamente uma vez".
• Projete para convergência, não para o último escritor a vencer por relógio. Relógios de parede em máquinas diferentes discordam. Use versionamento lógico (relógios vetoriais, timestamps de Lamport), logs de eventos somente de adição ou CRDTs (contadores, conjuntos, registradores com funções de mesclagem definidas) para que atualizações concorrentes se mesclem deterministicamente em vez de uma sobrescrever a outra silenciosamente.

O Modelo Mental para Levar Adiante

Pare de pensar no banco de dados como uma única folha de papel contendo a verdade atual e comece a pensar nele como um log de coisas que aconteceram, mais muitos leitores em diferentes pontos desse log. ACID lhe deu a ilusão de que todos estão no mesmo ponto do log o tempo todo; essa ilusão é acessível em uma máquina e cara em muitas.

Seu trabalho como engenheiro não é mais "tornar tudo consistente". É identificar o pequeno número de invariantes que nunca devem ser violados — dinheiro, unicidade, contagens não negativas, autorização — pagar pela consistência forte exatamente lá, e deixar todo o resto convergir em seu próprio cronograma enquanto a UI conta ao usuário uma história honesta sobre o que está acontecendo. Uma vez que você possa articular para qualquer recurso dado quão obsoleto é demais, e o que quebra se excedermos isso, você fez a transição.