Padrão: chaves de idempotência
O curso monta uma guarda de idempotência em Rails, peça por peça. O ponto de partida é uma chave check-then-store que deixa cinco threads concorrentes criarem registros de XP duplicados. A correção reordena os passos em reivindicar, trabalhar e concluir, para que o índice único decida antes do trabalho. Depois vêm as reações de quem perde a reivindicação, com o 409 Conflict usado pela Stripe, a impressão digital dos parâmetros com rejeição por 422, a escolha entre Postgres e Solid Cache e o projeto da própria chave.
O que você vai aprender
- ✓Por que uma chave check-then-store deixa requisições concorrentes duplicarem o trabalho
- ✓A ordem reivindicar, trabalhar, concluir com um status pending
- ✓Consultar de novo, bloquear ou falhar rápido com 409 quando se perde a reivindicação
- ✓Impressão digital da requisição e resposta 422 para chaves reusadas com outros parâmetros
- ✓Diferenças entre uma tabela Postgres e o Solid Cache para guardar reivindicações
- ✓Como escolher entre um UUID aleatório e uma chave derivada de campos estáveis
Chaves duplicadas vs. trabalho duplicado
A aula 3 do curso de nível Pleno "Service objects: idempotência" mostrou um formato check-then-store: procurar a chave de idempotência e, se ela não existir, fazer o trabalho e depois salvar a chave. Ela usou um service de pagamento hipotético. Aqui está o mesmo formato aplicado a uma concessão de…
Ler a aula completa grátis →Currículo
7 aulasChaves duplicadas vs. trabalho duplicado
Cinco threads concorrentes rodam uma guarda check-then-store com a mesma chave e criam quatro registros de XP.
Reserve antes de trabalhar
Reivindicar a chave em estado pending antes do trabalho faz o índice único barrar XP duplicado.
O que a perdedora faz
Compara consultar de novo, bloquear e falhar rápido, com a Stripe e um rascunho do IETF usando 409.
A chave significa a requisição, não só a operação
Guardar uma impressão digital dos parâmetros permite rejeitar com 422 uma chave reusada com outro payload.
Onde a reserva mora
Compara a reivindicação numa tabela Postgres e no Solid Cache em durabilidade, auditoria e expiração.
Projetando a chave em si
Chaves aleatórias falham quando o cliente recarrega a página; chaves derivadas de campos estáveis sobrevivem a quedas.
Juntando as chaves de idempotência
Remonta a guarda completa, explica onde ficam o rescue e o retry e propõe um desafio em Ruby puro.