Corretude de dados distribuídos
Comece pelo contrato
Escreva o invariante, seu escopo e as falhas que ele deve suportar. "Um pedido é cobrado no máximo uma vez" é útil; "consistência forte" é insuficiente. Identifique o registro autoritativo, as visões derivadas, os atores e cada limite de commit/confirmação. Pergunte se os clientes precisam de leia-suas-escritas, ordem causal, operações linearizáveis, transações serializáveis, ou apenas convergência eventual.
Procedimento de revisão
- Desenhe o caminho de escrita, incluindo commit no banco, confirmação do broker e efeitos colaterais externos. Registre o que cada resposta bem-sucedida garante após uma falha de processo, perda de máquina ou failover de réplica. Um tempo limite significa resultado desconhecido, não necessariamente execução falha.
- Enumere as janelas de falha antes e depois de cada etapa durável. Para cada uma, repita a operação e verifique o invariante. Teste tentativas concorrentes, bem como retentativas sequenciais. Use o registro de falhas.
- Mantenha um efeito de negócio e seu marcador de deduplicação em uma transação quando eles compartilham um banco de dados. Para eventos de saída, considere uma caixa de saída transacional. Para efeitos remotos, exija um contrato de idempotência durável do provedor ou uma máquina de estados de reconciliação. As garantias de entrega do broker param no seu limite de transação documentado.
- Identifique o escopo de ordenação: chave, partição, stream ou global. Escolha o escopo mais restrito que preserve o invariante. Um log particionado ordena suas partições; ele não ordena automaticamente eventos relacionados em partições diferentes.
- Para replicação e failover, inspecione eleição, fencing, política de confirmação e
recuperação.
R + W > Nfornece interseção de conjuntos sob associação fixa; isso sozinho não estabelece linearizabilidade. Veja consistência. - Para sharding, verifique localidade de transação, chaves quentes, rebalanceamento e aplicação de unicidade. Meça o shard mais ocupado, não apenas a taxa de transferência agregada.
- Produza o menor contraexemplo para uma garantia duvidosa e um teste que exercite-o. Separe garantias exigidas de obsolescência aceitável.
Saída da revisão
Retorne: invariante → suposições → linha do tempo de falha → garantia violada → correção mínima → custos → validação. Inclua um caminho de recuperação para dados já inconsistentes. Nomeie qualquer comportamento que dependa de uma versão de banco, broker ou provedor.
Verifique antes de recomendar
- Uma requisição repetida pode reutilizar seu ID de operação estável com parâmetros alterados?
- Um detentor de lease precisa de um token de fencing monotonicamente crescente imposto pelo recurso? A expiração do lease sozinha não pode parar um processo pausado.
- Réplicas podem servir valores obsoletos imediatamente após uma escrita bem-sucedida?
- Registros de tombstone ou deduplicação expiram antes do horizonte de repetição?
- Um invariante de múltiplos registros exige uma transação ou coordenação explícita?
Escopo e referências
Cobertura parcial alinhada com Designing Data-Intensive Applications, 2ª ed. (Kleppmann e Riccomini). Estes procedimentos originais usam notas de curso públicas do autor e documentação primária adicional; o livro completo não estava disponível. Leia fontes para atribuição exata. Esta skill não fornece uma implementação de consenso nem assume tolerância a falhas bizantinas.