IOSOR

IOSOR Guias

DLR, latência e failover: uma só verdade para produto e finanças

Unifique DLR, faixas de latência por corredor e failover com honestidade prepago, para que produto, operações e finanças deixem de disputar o mesmo webhook.

O produto quer conversão. As finanças querem débitos previsíveis. As operações querem uma palavra de estado que signifique o mesmo no painel, no webhook e na fatura. Quando DLR, latência e failover vivem em três silos, cada incidente vira briga de vocabulário — e o prepago queima enquanto as equipas discutem.

A IOSOR opera mensagens prepago white-label com um único dicionário de estados entre canais: erros seguros para o cliente, sem nomes de marcas alheias. O catálogo só promete capacidade quando está live; in setup não é live. Perto de USD 1.000+ de uso mensal, os exports de estado terminal, as faixas de latência e o débito de cada failover passam a revisão comercial. Evidência primeiro, escala depois.

Uma tabela de verdade para a liderança

Camada Pergunta de produto Pergunta de finanças Artefacto partilhado
DLR O utilizador recebeu? A entrega é faturável? Estado terminal + carimbo de tempo
Latency Dentro do SLA? N/A salvo se as novas tentativas multiplicarem o débito p95/p99 por corredor
Failover Que caminho ganhou? Quantas tentativas foram debitadas? Registo de tentativas + ID de correlação

Integração DLR que resiste a auditorias

  • Eventos inbound assinados ou autenticados
  • Consumidores idempotentes com chaves de desduplicação
  • Correlação envio → estado → livro-razão
  • Inspeção de entregas recentes dentro do produto

Um webhook sem assinatura e um consumidor não idempotente transformam novas tentativas em tickets duplicados e débitos duplicados. Veja guia operacional de entregabilidade SMS e não entregue, rejeitado e expirado. Catálogo live sem correlação DLR–livro é uma promessa que as finanças não podem defender.

Faixas de latência, não médias de vaidade

Meça accepted → submitted → delivered por corredor. A conversão OTP tem forma geográfica; uma média mundial esconde um mercado partido. Quando a latência degrada, decida nova tentativa vs failover vs paragem com responsáveis nomeados — não com esperança. Corte p95/p99 no relatório semanal.

Failover com disciplina prepago

O failover salva utilizadores — ou queima carteiras:

  1. Tecto de tentativas automáticas por mensagem.
  2. Separe o reenvio do utilizador do failover de sistema.
  3. Nunca faça failover para entradas de catálogo in setup.
  4. Documente as regras de débito por tentativa.

Rotas mock numa cadeia de failover de produção não são rede de segurança. Emparelhe o recuo voz/SMS com alertas de voz e fallback OTP. Produto e finanças devem exportar todas as tentativas de uma mensagem e alinhar IDs de correlação. live é o único destino legítimo; in setup não cobre um OTP de produção.

Sinais de alerta

  • Delivered e sent usados como sinónimos na interface
  • Tentativas de failover invisíveis para as finanças
  • Rotas mock em cadeias de failover de produção
  • Palavras de estado diferentes entre webhook e fatura
  • Só capturas de ecrã como prova
  • Failover prometido enquanto o catálogo está in setup
  • Nomes de marcas alheias em erros visíveis ao cliente

Começar com IOSOR

Escolha um corredor e um tipo de mensagem. Exporte os DLR terminais da semana passada para um dicionário partilhado produto–finanças e passe o mesmo correlation ID por staging, failover e o débito da carteira. Simule uma troca de caminho e compare o que o utilizador viu com o que o ledger cobrou. Corrija qualquer rótulo Delivered se as finanças ainda tiverem um retry ou um débito de failover.

Conclusão IOSOR

Produto e finanças devem ler um DLR, um relógio de latência e um resultado de failover no mesmo correlation ID. Um débito sem estado visível para o utilizador é mentira.

Este guia foi útil?

Guias relacionados