Visibilidade e durabilidade são perguntas diferentes

Agora altere a hipótese: L falha depois de confirmar v9, antes de R recebê-la. Se uma política promover R sem recuperar aquela escrita, o endereço confirmado pode desaparecer do estado disponível. Persistência local em um nó não equivale a sobrevivência à perda desse nó.

Para prometer sobrevivência, é preciso especificar quais confirmações são exigidas e quais candidatos podem assumir liderança. Mais participantes na confirmação podem acrescentar espera e dependência de comunicação. Uma réplica atrasada oferece um problema de visibilidade; uma promoção sem a escrita confirmada acrescenta risco de perda. As soluções e custos não são os mesmos.

Se a resposta de T1 se perder, o cliente enfrenta outra situação: resultado desconhecido. Timeout não informa se houve confirmação. Uma identidade estável de operação e consulta de resultado podem ajudar, desde que o sistema mantenha esse contrato. Gerar uma identidade nova a cada tentativa torna mais difícil reconhecer a repetição da mesma intenção.

Transações protegem um conjunto definido de decisões

Imagine que editar o endereço também deve acrescentar um registro de auditoria. Se ambos pertencem à mesma confirmação, grave-os atomicamente no armazenamento que oferece essa garantia. Um teste deve verificar falha entre as etapas e ausência de estado parcialmente aplicado.

Isso não torna uma leitura posterior em réplica automaticamente recente. Atomicidade de escrita e visibilidade de leitura tratam de partes diferentes da operação. Também não transforme o nome de um nível de isolamento em promessa sobre qualquer sequência concorrente; investigue o comportamento documentado e as anomalias que a aplicação precisa impedir.

Kleppmann questiona classificações simplificadas em Please stop calling databases CP or AP. A discussão enfatiza definições precisas e propriedades por operação. Para o perfil, perguntar quem lê o quê depois de qual confirmação esclarece mais que atribuir duas letras ao banco inteiro.

Dados derivados ampliam o contrato

O perfil também pode alimentar um índice de busca e um relatório. Atualizar o registro principal não atualiza necessariamente essas representações no mesmo instante. Se a busca retornar Rua A enquanto a tela de edição mostra Rua B, precisamos saber se isso é atraso permitido ou violação de uma expectativa do produto.

Processamento em lote pode reconstruir um relatório a partir de um conjunto delimitado; processamento em fluxo acompanha alterações conforme chegam. Ambos exigem decisões sobre repetição, completude e evolução de formato. A utilidade está em compreender como resultados são produzidos e reconstruídos, sem declarar que um mecanismo sempre substitui o outro.

Defina a origem de referência, o ponto até o qual a derivação avançou e a política para falhas. Reprocessar dados pode recuperar resultados, mas também reproduzir efeitos externos se o consumidor não distingue reconstrução de uma ação nova. O caminho entre dados persistidos e experiência do usuário merece a mesma atenção que a escrita inicial.

Um exercício que conecta conceito e verificação

Escolha um ambiente controlado e uma configuração real de replicação. Registre versão, topologia e política de confirmação. Reproduza atraso de aplicação na réplica, execute a escrita e compare leituras da sessão. Separe uma expectativa de leitura das próprias escritas de qualquer promessa de sobrevivência a falhas.

Depois simule perda de resposta e uma mudança de liderança, conforme os mecanismos disponíveis. Observe se a aplicação consegue recuperar o resultado ou precisa comunicar incerteza. Não use o exercício para afirmar garantias que o ambiente não foi configurado para oferecer.

A tabela desta resenha não executou esses testes. Ela serve para escrever expectativas e localizar evidências ausentes. Um resultado bem-sucedido em um cenário também não cobre toda falha possível; mantenha explícitos os casos, hipóteses e limitações da verificação.

Pontos fortes e críticas

O mérito é o método comparativo. Você ganha perguntas para distinguir custo de escrita, latência, disponibilidade e recuperação. Isso ajuda a desafiar tanto a escolha de um produto por popularidade quanto a ideia de que um único mecanismo resolve todos os riscos.

A amplitude também é seu limite. Conhecer conceitos não equivale a operar uma migração ou recuperar um banco sob pressão. O leitor pode adquirir vocabulário antes de adquirir julgamento operacional. Combine a leitura com documentação, acompanhamento de quem opera o sistema e experimentos que mostrem as consequências das configurações.

Produtos e exemplos da edição de 2017 refletem aquele período. Use os conceitos como ponto de partida e confira a documentação da versão implantada antes de transportar uma afirmação específica. Uma comparação histórica não estabelece o comportamento atual de um serviço gerenciado nem inclui automaticamente seus limites de contrato.

Para quem recomendo e quando adiaria

Recomendo para quem já entende consultas SQL básicas, índices e comunicação entre processos. Não é preciso administrar um grande cluster para aproveitar, mas ajuda ter observado uma escrita, uma leitura e uma falha de rede. Um iniciante pode começar por esses experimentos e voltar aos capítulos conforme surjam perguntas.

Se a necessidade imediata é aprender a consultar uma tabela ou corrigir uma conexão, um material introdutório e a documentação do banco podem trazer retorno mais rápido. Também não adote distribuição só para praticar o livro. Um armazenamento simples que satisfaz o contrato evita coordenação que talvez seu produto ainda não necessite.

Implementing DDD ajuda a formular invariantes comerciais. Release It! complementa a análise de falhas operacionais. Clean Architecture discute dependências. DDIA aprofunda os mecanismos que precisam sustentar essas decisões; separação de camadas não escolhe a garantia de uma leitura.

Plano de leitura e veredito

Descreva uma operação real com entradas, consulta, escrita e consequência visível. Leia armazenamento e replicação, depois transações e falhas, revisando sua linha do tempo. Explore processamento derivado quando houver busca ou relatório separado.

Para cada alternativa, registre garantia desejada, custo aceito e hipótese que exige teste. Compare com a implementação atual antes de propor substituições. A prática não precisa terminar numa troca de banco.

Recomendo a primeira edição pelo raciocínio desenvolvido: distinguir dado ainda invisível, dado perdido e resultado desconhecido, explicando como chegam ao usuário. Comece pela promessa e verifique o que a sustenta.