13.2. Corretude: end-to-end, restrições e verificação
Garantias de cada camada não bastam; IDs de requisição de ponta a ponta e auditoria contínua garantem integridade.
Resumo
- Argumento end-to-end: só as pontas garantem corretude. TCP e transações não deduplicam um clique repetido.
- Solução: ID de requisição gerado no cliente, levado até o banco, com restrição de unicidade.
- Restrições (unicidade, saldo) via stream: particionar por chave e processar em ordem; aceitar ou rejeitar de forma determinística.
- Integridade (não corromper, não perder) é inegociável; atualidade (ver logo) pode ser fraca. Compensar depois às vezes basta.
- Trust, but verify: discos e software erram. Faça auditoria, checksums e reprocessamento para detectar corrupção.
Perguntas-chave
responda de cabeça, depois abraPor que transação de banco não impede pagamento duplicado?
Se o cliente reenviar após timeout, são duas transações válidas diferentes; só um ID único de ponta a ponta revela que é a mesma intenção.
Qual a diferença entre atualidade e integridade?
Atualidade é ver o estado mais recente; integridade é não ter dados corrompidos ou perdidos. Violação de atualidade passa; de integridade, não.
Por que auditar se o banco é confiável?
Bugs, falhas de hardware e erros de operação corrompem dados em silêncio; verificar periodicamente detecta antes que se espalhe.
Exercícios de fixação
0/5 respondidas1.
O usuário clica duas vezes em "Pagar". O banco usa transações serializáveis. Por que pode haver cobrança dupla?
2.
Como impor "nome de usuário único" num sistema baseado em streams?
3.
Uma companhia aérea vende mais assentos que o avião e oferece compensação depois. Isso mostra que:
4.
Qual violação é mais grave segundo o capítulo?
5.
"Trust, but verify" na prática significa: