Limites de velocidade de SMS A2P por destino: como acordá-los e gerenciá-los
Um limite de TPS declarado não garante a entrega. Saiba como definir seu escopo, controlar filas por destino e avaliar sinais operacionais sem confundir aceitação com entrega.
Um TPS declarado não é uma garantia de entrega
TPS costuma ser usado para expressar mensagens por segundo, mas o número anunciado só é útil para a operação quando se sabe o que mede, onde se aplica e em quais condições. Não existe um limite universal que possa ser deduzido apenas pelo país, pela operadora ou pelo tipo de conexão: é preciso confirmá-lo com quem administra a rota e registrar seu escopo.
Também é necessário separar as etapas do envio. Uma resposta de aceitação confirma, no máximo, que uma solicitação foi admitida naquele ponto da cadeia; por si só, não comprova que o SMS chegou ao telefone. Os estados posteriores, incluindo os DLRs, devem ser interpretados conforme sua origem e nível de verificação.
- Trate o TPS informado como uma condição a esclarecer, não como uma promessa geral de entrega.
- Registre separadamente a admissão das solicitações e os estados posteriores da mensagem.
- Não extrapole o valor de uma rota para outros destinos, operadoras ou remetentes.
O que definir antes de configurar o tráfego
Solicite uma definição por escrito do escopo do limite e de como ele é medido. Esclareça se se aplica ao país, a uma operadora, a uma rota, a um remetente, a uma conta ou a uma sessão. Pergunte também se varia conforme o tipo de tráfego, por exemplo, OTP, transacional ou marketing legítimo, e qual janela de tempo é usada no cálculo.
A conexão não substitui esse acordo. O SMPP define aspectos da troca entre uma aplicação e um SMSC, e o HTTP descreve a semântica de solicitações e respostas; nenhuma dessas especificações, por si só, estabelece um TPS garantido para uma rota A2P nem confirma a entrega à rede móvel.
- Destino e operadora ou grupo de operadoras abrangidos.
- Identificador da rota, conta, remetente e tipo de tráfego incluídos.
- Unidade, janela de medição e tratamento das solicitações rejeitadas.
- Limite por sessão e limite agregado, se ambos existirem.
- Condições aplicáveis a rajadas, simultaneidade, pausas e mudanças de capacidade.
- Códigos de resposta e contato operacional para incidentes ou ajustes.
Diferencie taxa sustentada, rajada e simultaneidade
Não presuma que uma taxa nominal significa que esse volume pode ser enviado continuamente. Peça ao provedor que defina se o valor é sustentado, um máximo instantâneo ou uma média durante uma janela determinada. Se houver rajadas permitidas, solicite as condições e a duração; se houver limites para sessões ou solicitações simultâneas, registre-os separadamente.
As evidências disponíveis não permitem recomendar valores universais para esses parâmetros. Se o provedor não conseguir defini-los, marque a condição como não confirmada e evite projetar o sistema com base em uma interpretação otimista.
- Documente cada parâmetro separadamente; não reduza todos os limites a um único TPS.
- Diferencie a taxa de mensagens, o número de solicitações simultâneas e as sessões de conexão.
- Anote se o limite é compartilhado entre destinos, remetentes ou conexões, ou se o provedor ainda não esclareceu essa informação.
Projete controles de admissão e filas por destino
Organize o tráfego em filas que correspondam ao escopo real de cada limite. Se um provedor confirmar limites diferentes por operadora ou rota, evite que uma fila global oculte o excesso em um desses grupos. Antes de colocar o controle em produção, verifique como o destino é identificado e o que acontece com as mensagens cujo roteamento ainda não foi definido.
A taxa de saída deve poder ser ajustada sem descartar mensagens silenciosamente. Defina o que fica na fila, o que é reenviado e como evitar que novas tentativas ampliem uma situação de saturação. Os critérios específicos dependem do acordo e do comportamento observado; não há uma configuração universal que possa ser recomendada sem esses dados.
- Associe cada fila a um limite confirmado e mantenha essa relação na configuração.
- Defina regras explícitas para pausar, retomar e reenviar após rejeições.
- Registre as mudanças de taxa e configuração para relacioná-las aos resultados.
- Garanta que as prioridades de tráfego não anulem as restrições do destino.
Interprete os sinais operacionais em contexto
Um aumento nas rejeições ou na latência da resposta de aceitação pode indicar que uma restrição está sendo atingida, mas não identifica a causa por si só. Verifique se coincide com uma mudança de volume, rota, sessão ou configuração, e peça ao provedor que interprete os códigos de resposta. Não atribua automaticamente o problema a um limite de TPS.
Monitore também a profundidade e a idade das filas, as solicitações aceitas em comparação com as rejeitadas e os estados posteriores disponíveis. A latência de admissão e o DLR descrevem etapas diferentes; um DLR recebido não deve ser apresentado como verificação independente de recebimento no telefone se essa verificação não existir.
- Rejeições: contabilize por código, destino, rota e período.
- Latência: separe o tempo de resposta da API ou sessão dos estados posteriores.
- Filas: acompanhe a profundidade, a idade e a velocidade de esvaziamento.
- Estados: diferencie aceitação, DLR e qualquer confirmação de recebimento realmente verificável.
Teste de forma gradual e com consentimento
Antes de um teste, combine com o provedor o destino, o remetente, o tipo de tráfego, a janela, a taxa inicial e as condições para interrompê-lo. Use apenas mensagens legítimas e destinatários que tenham consentido em receber o tráfego, cumprindo as regras aplicáveis. Não aumente a carga sobre destinos reais sem autorização explícita.
Aumente o volume de forma controlada, registre cada mudança e interrompa o teste diante dos sinais de erro ou saturação acordados. Um teste demonstra o comportamento observado naquelas condições; não transforma o resultado em capacidade de produção garantida nem em evidência aplicável a outras rotas ou períodos.
- Combine antecipadamente o escopo e os critérios de interrupção.
- Mantenha constantes as variáveis que não estiver avaliando e documente qualquer mudança.
- Não use um teste não autorizado como substituto de uma confirmação contratual.
Responda a uma possível saturação
Diante de um aumento persistente de rejeições, latência ou tamanho da fila, reduza a taxa de admissão e siga o procedimento acordado. Se a deterioração continuar, pause o tráfego afetado quando apropriado e entre em contato com o provedor, fornecendo dados concretos. Não aumente automaticamente a simultaneidade nem acelere as novas tentativas: sem conhecer as regras da rota, essas ações podem aumentar a pressão ou dificultar o diagnóstico.
Mantenha uma cronologia do incidente: horário, destino, rota, volume, mudanças de configuração, códigos recebidos e evolução das filas. Peça confirmação sobre se algum limite foi atingido, se houve uma condição operacional diferente ou se o limite vigente mudou. Escale pelos canais acordados e registre a resposta.
- Reduza a taxa afetada e evite novas tentativas agressivas que não tenham sido acordadas.
- Forneça códigos de erro e métricas segmentados por destino e rota.
- Solicite uma decisão operacional e a confirmação por escrito de qualquer mudança de limite.
- Retome gradualmente conforme o procedimento acordado.
Revise os limites e preserve as evidências
Mantenha um registro versionado que separe as condições informadas pelo provedor do que foi observado em produção. Inclua a data da confirmação, o escopo, os parâmetros, as exceções e a pessoa responsável por validar qualquer mudança. Se as métricas diferirem do que foi acordado, solicite uma revisão; não substitua o limite contratual pelo máximo observado em um teste breve.
Revise o registro quando houver mudanças na rota, no destino, no remetente, na sessão ou no padrão de tráfego, e também após incidentes relevantes. A BulkSMSMarket está desenvolvendo uma plataforma empresarial para descobrir, comparar, comprar, vender e gerenciar capacidade de SMS A2P; seus cartões numéricos públicos são demonstrativos até que dados contratuais das rotas sejam conectados. Portanto, eles não devem ser tratados como limites comerciais ativos.
- Mantenha separados o limite informado, a configuração aplicada e as evidências observadas.
- Registre o período e as condições de qualquer teste ou incidente.
- Revise o acordo com o provedor antes de alterar a capacidade operacional.
Perguntas frequentes
Existe um limite universal de TPS para SMS A2P por país?
As informações disponíveis não permitem estabelecer um valor universal. Confirme o limite com quem administra a rota e documente a quais destino, operadora, remetente, sessão e janela de medição ele se aplica.
A aceitação da solicitação significa que o SMS foi entregue?
Não. A aceitação indica que a solicitação foi admitida em um ponto do processo, mas não comprova, por si só, a entrega ao telefone. Interprete separadamente os estados posteriores e o grau de verificação que oferecem.
SMPP ou HTTP definem a velocidade garantida de uma rota?
Não, de acordo com as evidências disponíveis. SMPP e HTTP especificam aspectos da troca técnica, mas suas especificações não estabelecem, por si só, uma capacidade A2P garantida por destino.
O que fazer se os limites de rajada ou simultaneidade não estiverem definidos?
Peça uma definição por escrito e registre esses parâmetros como não confirmados até recebê-la. Não deduza seus valores com base no TPS nominal nem em um teste isolado.
Um teste bem-sucedido comprova a capacidade sustentável em produção?
Não necessariamente. Ele descreve apenas o comportamento observado nas condições do teste. O resultado não garante capacidade futura nem pode ser extrapolado automaticamente para outros destinos, rotas ou períodos.
Fontes consultadas
- SMPP Protocol Specification v3.4SMPP Developers Forum
- HTTP Semantics (RFC 9110)Internet Engineering Task Force
- 3GPP specifications by series3GPP
- ITU-T Recommendation E.164International Telecommunication Union
- GSMA networks resourcesGSMA