AULA 26 / 30 · Parceiros e operação
Postbacks: fila, retries e status de entrega
Leia delivered, retry_wait, dead_letter e suppressed.
Guia baseado em documentação e PRs consultados. SDKs/API citados ainda têm alterações em draft; confirmar release e homologação.
Ver implementação e critérios de aceite →Entrega assíncrona
O desenho usa outbox após decisão elegível. Um timeout do parceiro não deve bloquear o redirect ou o primeiro acesso. O worker precisa aplicar timeout, retry com jitter e chave idempotente estável.
Estados claros
delivered confirma o resultado do adapter; retry_wait é falha transitória aguardando tentativa; dead_letter é falha terminal/limite; suppressed indica inelegibilidade. Preservado nativamente no Google não é uma campanha perdida.
Auditoria mínima
Guarde parceiro, evento, schema, consentimento, tentativas, próxima tentativa, código de resposta, timestamps, idempotency_key e hash do payload. Segredos e payload sensível pertencem a armazenamento protegido, não ao print da Academy.
Referência versus operação
A API de parceiros do lab tem adapters locais e persistência de referência. Não há comprovação de scheduler permanente e envio HTTP homologado às redes. Teste replay, rate limit, falha permanente, revogação e rollback em staging.
SUA VEZ
Leve a aula para a prática
Monte uma linha auditável para um envio que falhou duas vezes e depois foi entregue. Preserve a mesma chave de idempotência.
Baixar checklist de homologação ↓Confira o aprendizado
Documentação e evidências
Consultadas em 03/10/2026. Os exercícios e números desta aula são fictícios.