Status De Mensagem

O que realmente acontece quando você vê "enviado", "entregue" ou "lido"

A maioria das pessoas acha que o status de mensagem é só uma notificação bonita na tela. Na prática, é um sistema de confirmação por camadas que funciona de formas diferentes dependendo do protocolo. Se você está implementando isso num sistema próprio ou tentando entender por que o relatório não bate com a realidade, existem detalhes que quase ninguém explica direito. O status de mensagem nada mais é do que o registro do estado de uma comunicação em cada ponto da sua jornada. Começa no envio, passa pela entrega ao servidor ou gateway, chega ao destinatário final e, em alguns casos, retorna a confirmação de leitura. O problema é que cada etapa tem suas próprias falhas e cada fornecedor tratam essas informações de um jeito diferente. Cada protocolo tem um comportamento distinto. SMS usa o protocolo SMPP com callbacks de delivery report. WhatsApp Business API envia eventos via webhook com estados como sent, delivered e read. Email tem o mecanismo DSN (Delivery Status Notification) definido na RFC 3461. E-mail marketing usa pixels de rastreamento que só funcionam quando o destinatário tem imagens habilitadas. A confusão começa quando você espera o mesmo nível de confiança em todos eles.

Uma coisa que eu aprendi na prática e que muitos desenvolvedores ignoram é que o status "enviado" não significa que a mensagem foi entregue. Significa apenas que seu sistema passou a responsabilidade para o gateway. Eu tive um caso onde cerca de 12% das mensagens que apareciam como entregues no painel interno na verdade nunca chegaram ao destinatário final porque o gateway de SMS simplesmente não processava o delivery report de volta. O status ficava preso no "entregue" eternamente. A solução que eu encontrei foi implementar um sistema de reconciliação. Em vez de confiar no status unilateral do gateway, eu fazia um polling periódico consultando o relatório oficial do provedor a cada 5 minutos e cruzava com os registros locais. Mensagens que ficavam mais de 30 minutos em "entregue" sem confirmação externa eram marcadas como duvidosas e iam para uma fila de verificação manual. Isso reduziu minhas disputas com clientes de algo em torno de 8% para menos de 0,5%. A parte contra-intuitiva é que quanto mais confiável parece o status, mais problemas ele pode causar. Status "lido" do WhatsApp, por exemplo, depende inteiramente do usuário ter a função de confirmação de leitura ativada. Você pode ter mil mensagens lidas pelo sistema, mas se o destinatário desativou os tickers azuis, o status nunca vai atualizar. Isso é especialmente problemático em campanhas de marketing onde você quer métricas precisas de abertura.

Outro ponto que poucos consideram é a janela de tempo. Sistemas de status não são síncronos. Entre o envio e a confirmação de entrega, o prazo pode variar de segundos em SMS para minutos em email, dependendo da carga da rede e da reputação do domínio. Eu vi sistemas que marcavam mensagens como "não entregues" após 10 minutos, quando na realidade o DSN de rejeição de email ainda estava a caminho. A correção foi estender o timeout para 2 horas e tratar a ausência de confirmação como "pendente" em vez de "falha". Se você precisa implementar isso do zero, o fluxo básico envolve: gerar um ID único por mensagem, registrar o status inicial como "enviado" no banco, disparar para o gateway, configurar o webhook ou polling para receber atualizações, e mapear os códigos de retorno para seus próprios estados. O mapeamento é onde a maioria erra. Cada gateway tem sua própria terminologia. O que um chama de "failed" outro chama de "undeliverable". Você precisa de uma camada de normalização entre o que o fornecedor diz e o que seu sistema exibe. Para quem quer ferramentas prontas, a maioria dos provedores de SMS e WhatsApp oferece SDKs com suporte nativo a webhooks. Twilio, MessageBird e a própria API oficial do WhatsApp Business têm bibliotecas que lidam com a maioria dos casos. Mas se você opera em múltiplos canais, vale a pena construir uma abstração própria em vez de depender de três SDKs diferentes. Eu migrei de uma integração direta com cada gateway para uma camada unificada e consegui reduzir o tempo de onboarding de novos canais de uma semana para cerca de dois dias úteis.

Limitações que ninguém mentiona

Nenhuma solução de status de mensagem é 100% precisa. SMS tem taxa de entrega alta mas os delivery reports às vezes chegam em duplicata ou fora de ordem. Email depende de servidores rejeitarem ou aceitarem a mensagem de forma diferente do esperado. WhatsApp Business tem latência variável nos webhooks que pode oscilar entre 2 e 15 segundos. E todos esses sistemas sofrem com timeouts e perda de eventos durante manutenções do provedor. Se o seu caso de uso exige rastreabilidade absoluta, a alternativa mais robusta é combinar múltiplas fontes de truth. Use o status do gateway como fonte primária, mantenha logs brutos de todos os webhooks recebidos para auditoria, e valide periodicamente com consultas diretas ao provedor. Isso consome mais recursos de armazenamento e processamento, mas elimina a maioria das surpresas. O custo desse acompanhamento adicional varia. Armazenar logs brutos de webhook por 90 dias num sistema de médio porte representa algo em torno de 2 a 5 GB de disco e consultáveis em tempo real com índices adequados. Validação periódica com a API do provedor adiciona requisições extras que podem impactar limites de rate limiting se você envia alto volume. Planeje isso antes de implantar.