Como dimensionar TPS, filas e capacidade para picos de tráfego A2P SMS
Guia operacional para calcular TPS, dimensionar filas, separar prioridades e testar a capacidade de envio de A2P SMS sem confundir aceitação, DLR e receção final.
A questão operacional: quantos TPS uma operação A2P SMS realmente necessita
Dimensionar TPS não consiste em escolher um único valor para toda a plataforma. A pergunta útil é: quantas mensagens têm de ser aceites, processadas e enviadas dentro de uma janela operacional específica, para uma determinada combinação de destinos e classes de tráfego?
O TPS necessário deve ser calculado a partir do volume previsto e da janela-alvo. Como ponto de partida: TPS base = mensagens previstas / segundos da janela. Esta fórmula serve para planeamento, não constitui uma garantia de capacidade de uma API HTTP, de uma sessão SMPP, de um fornecedor, de uma rota ou de uma rede móvel.
O valor resultante deve ser documentado juntamente com os seus pressupostos: distribuição temporal, combinação de destinos, prioridade do tráfego, política de repetição, expirações e limites confirmados para cada ligação ou rota. Sem esses pressupostos, um TPS agregado pode ocultar um estrangulamento relevante.
- Defina o que significa “dentro da janela”: aceitação interna, aceitação pelo fornecedor ou estado final comunicado.
- Calcule por classe de tráfego e por destino, não apenas para o total agregado.
- Trate a margem como uma decisão explícita para rajadas, repetições e variação de rotas; não como uma garantia implícita.
- Valide os limites efetivos junto do fornecedor ou operador que gere cada capacidade.
Definir o pico: volume, janela, distribuição temporal e destinos
O volume diário ou mensal não dimensiona um pico. Duas operações com o mesmo volume podem exigir capacidades muito diferentes se uma distribuir os envios ao longo de horas e a outra tiver de os emitir em minutos. A unidade de análise deve ser o perfil temporal do evento, de preferência por minuto e, quando o caso o exigir, por segundo.
Também é importante separar os destinos. Um volume concentrado num país, rede, intervalo de numeração, remetente ou rota pode atingir limites antes do total da plataforma. Os números de destino devem ser geridos com uma normalização coerente com o plano internacional E.164 e com as regras de endereçamento aplicáveis à integração.
Os picos de autenticação estão frequentemente ligados a ações simultâneas de utilizadores ou a incidentes de acesso. As campanhas podem ser sincronizadas para uma hora de lançamento. Ambos os casos exigem um perfil de chegada realista, e não uma média diária.
- Mensagens previstas por intervalo de tempo.
- Janela-alvo por classe de tráfego.
- Distribuição por país, rede, rota e remetente.
- Percentagem esperada de OTP, transacional e campanha.
- Eventos que possam produzir rajadas: aberturas, lançamentos, recuperação de acesso ou processos em lote.
- Repetições previstas e as condições que as ativam.
Distinguir quatro limites de capacidade
Uma resposta de aceitação da interface não demonstra que a mensagem completou o percurso até ao destinatário. Para operar com rigor, separe pelo menos quatro etapas: aceitação da API HTTP ou SMPP, processamento e fila internos, aceitação ou processamento pelo fornecedor e estado final comunicado pela cadeia SMS.
No SMPP, submit_sm e submit_sm_resp refletem a troca entre o ESME e o SMSC. O resultado posterior pode ser comunicado através de um SMSC Delivery Receipt quando solicitado. Portanto, o TPS de submit_sm aceites não deve ser apresentado como TPS entregues nem como prova de receção no terminal.
Esta separação também melhora o diagnóstico. Se a aceitação local se mantiver estável mas a fila interna crescer, o limite está antes da saída. Se os pedidos pendentes aumentarem ou as respostas se degradarem, o problema pode estar na ligação ou no extremo remoto. Se o estado final variar por destino, a análise deve ser feita por rota e rede, e não apenas como média global.
- Limite de aceitação: pedidos que a interface admite.
- Limite de processamento: capacidade para validar, colocar em fila, priorizar e despachar.
- Limite de fornecedor ou rota: capacidade técnica e contratual confirmada para cada destino.
- Comportamento da rede: estados e tempos finais que podem variar ao longo da cadeia de entrega.
Cálculo base de TPS e margem documentada
O cálculo inicial é direto: divida o número de mensagens que têm de ser processadas pelos segundos disponíveis. Por exemplo, se uma operação tiver de aceitar e despachar um lote dentro de uma determinada janela, o TPS base representa a taxa média mínima para essa janela. Depois, compare essa taxa com o perfil temporal: se as chegadas se concentrarem no início, a taxa de entrada pode superar amplamente a média.
A margem não deve ser escolhida como um valor universal. Deve responder a uma hipótese concreta: uma rajada inicial, uma recuperação de sessão, um aumento temporário de pedidos, uma redistribuição de destinos ou repetições controladas. É preferível registar vários cenários — esperado, elevado e de contingência — do que ocultar todos os riscos sob um único multiplicador.
O cálculo deve ser repetido por partição operacional. Uma plataforma pode dispor de capacidade agregada suficiente e, ainda assim, não ter a capacidade necessária para um destino ou uma rota específicos.
- TPS base = mensagens previstas / segundos da janela.
- Calcule o TPS de entrada e o TPS de saída separadamente.
- Adicione margem apenas com uma causa operacional identificada.
- Compare o resultado com limites por rota, destino, ligação e classe de tráfego.
- Reveja o cálculo quando o perfil de destinos, a janela ou a política de repetição mudar.
Porque a média engana
Uma média suaviza precisamente o comportamento que causa incidentes. Se milhares de pedidos chegarem ao mesmo tempo, uma taxa média diária não explica a profundidade de fila necessária nem a antiguidade que as mensagens irão atingir. O desenho deve considerar a diferença entre a taxa de chegada e a taxa sustentável de saída em cada intervalo.
A concentração por destino também importa. Enviar para múltiplos destinos não equivale a enviar o mesmo volume para uma única rede. Os limites específicos não são normalizados por SMPP nem por HTTP: devem ser conhecidos através da documentação aplicável, dos acordos operacionais e da observação da rota real.
No caso de OTP, além disso, uma espera prolongada pode transformar uma mensagem tecnicamente processável numa mensagem inútil. Por isso, um pico não é gerido apenas aumentando a fila; exige decidir que tráfego é admitido, qual é adiado e qual deve expirar de forma controlada.
- Analise máximos por segundo ou por minuto, e não apenas médias.
- Meça a concentração por destino, rota, remetente e tipo de tráfego.
- Modele a chegada inicial de campanhas e eventos de autenticação.
- Defina o ponto a partir do qual cada classe de mensagem deixa de ser útil.
Dimensionar filas: profundidade, antiguidade e expiração
A profundidade de fila necessária depende do excesso temporário de entrada em relação à saída sustentável. Uma aproximação operacional consiste em calcular o máximo acumulado da diferença entre a taxa de chegada e a taxa de serviço durante o pico. Se entrarem mais mensagens do que as que podem sair, o diferencial acumula-se; quando a saída voltar a superar a entrada, a fila é escoada.
A profundidade por si só não é suficiente. Defina uma antiguidade máxima aceitável por classe de tráfego. Uma fila pode conter todas as mensagens e continuar a comprometer a utilidade de um OTP ou de uma notificação transacional sensível ao tempo. A antiguidade deve ser medida a partir de um timestamp definido e consistente, por exemplo, desde a aceitação do pedido pela plataforma.
O SMPP permite indicar um validity_period, que representa uma hora de expiração no SMSC após a qual a mensagem deve ser descartada se não tiver sido entregue. Esta capacidade não substitui uma expiração funcional da própria aplicação: a plataforma deve evitar que uma mensagem sem valor permaneça desnecessariamente em filas internas ou concorra com tráfego crítico.
- Calcule a acumulação máxima prevista durante o pico.
- Estabeleça um limite de antiguidade para cada classe de tráfego.
- Defina o que acontece ao ultrapassar a antiguidade: cancelar, expirar ou informar o sistema originador.
- Alinhe a expiração interna com o validity_period e com as regras do fornecedor, quando aplicável.
- Meça profundidade e antiguidade por fila, destino e prioridade.
Separar OTP, mensagens transacionais e campanhas
OTP, tráfego transacional e campanhas não devem partilhar uma única fila sem controlos. A classificação é uma decisão de produto e operação, mas deve traduzir-se em políticas explícitas de admissão, prioridade, reserva de capacidade, expiração e degradação.
Os OTP normalmente exigem uma antiguidade funcional muito curta. As mensagens transacionais podem ter uma tolerância diferente consoante o processo de negócio. Já as campanhas legítimas e consentidas são, em geral, candidatas a um agendamento mais flexível quando a capacidade está sob pressão. A política deve ser conhecida pelo produto, pelas operações e pelos sistemas que originam as mensagens.
O SMPP inclui priority_flag e campos relacionados com o serviço, mas a norma não prescreve uma política de filas nem garante que uma marca de prioridade produza o mesmo resultado em todas as implementações. A prioridade deve ser aplicada principalmente na própria plataforma e coordenada com as condições da rota.
- Reserve capacidade ou admissão para tráfego crítico quando necessário.
- Evite que uma campanha consuma a fila ou a capacidade destinada a OTP.
- Atribua antiguidade máxima e ação de expiração por classe.
- Registe o motivo de cada degradação para análise posterior.
- Mantenha os envios legítimos, consentidos e sujeitos às regras aplicáveis.
Orçamentos de latência e semântica dos DLR
Um orçamento de latência útil divide o percurso em etapas observáveis: tempo até à aceitação da API ou SMPP, espera na fila própria, tempo até à aceitação ou processamento pelo fornecedor e tempo até ao estado final comunicado. Cada etapa deve ter o seu timestamp, fonte e método de correlação.
Não equipare a resposta inicial à receção final. No SMPP, a resposta a submit_sm confirma a troca do pedido com o SMSC, enquanto o resultado posterior é comunicado através de um delivery receipt quando solicitado. Os estados podem incluir, entre outros, DELIVRD, EXPIRED, UNDELIV e REJECTD.
Nem todos os relatórios de entrega têm a mesma semântica. A 3GPP distingue relatórios emitidos pelo Service Centre dos emitidos pela estação móvel. Por isso, um DLR emitido por um SMSC ou por uma rede intermédia deve ser identificado pelo seu emissor e significado. Não deve ser apresentado automaticamente como prova independente de receção no terminal.
- Meça a latência por etapa, e não apenas um tempo total.
- Use percentis para identificar filas longas e degradação da fila.
- Conserve a fonte do estado: plataforma, fornecedor, SMSC ou outra parte da cadeia.
- Diferencie aceitação, estado final comunicado e receção no terminal quando existir evidência dessa natureza.
- Evite promessas de receção final baseadas apenas numa resposta inicial ou num DLR com semântica não confirmada.
Perguntas frequentes
Como se calcula o TPS necessário para A2P SMS?
Como ponto de partida, divida as mensagens previstas pelos segundos da janela-alvo. Depois, calcule por destino, rota, ligação e classe de tráfego, e documente separadamente a margem para rajadas, repetições e variação operacional. O resultado é uma necessidade de planeamento, e não uma garantia de capacidade de rede.
Um submit_sm_resp bem-sucedido significa que o SMS chegou ao telemóvel?
Não. O submit_sm_resp reflete a resposta ao pedido SMPP entre o ESME e o SMSC. O resultado posterior exige observar o delivery receipt quando solicitado e analisar o seu estado e semântica. Um DLR emitido por um SMSC não demonstra automaticamente a receção no terminal.
Como se calcula o tamanho de uma fila SMS?
Estime o máximo acumulado durante os intervalos em que a taxa de chegada excede a taxa sustentável de saída. Além da profundidade, defina uma antiguidade máxima por classe de tráfego e a ação a tomar quando esse limite for ultrapassado, como expiração ou cancelamento controlado.
Porque devo separar OTP e campanhas?
Porque os seus requisitos de utilidade e espera são diferentes. Uma campanha pode ser agendada ou reduzida quando existe pressão de capacidade, enquanto um OTP normalmente perde valor se esperar demasiado. As políticas devem separar admissão, prioridade, antiguidade e degradação.
Como influencia o SMPP o dimensionamento da concorrência?
O SMPP permite pedidos assíncronos e utiliza sequence_number para correlacionar pedidos e respostas. Uma aproximação útil é estimar os pedidos em curso como TPS-alvo multiplicado pela latência observada de submit_sm_resp. O limite final deve ser ajustado por sessão de acordo com a documentação, erros, timeouts e comportamento observado do fornecedor.
Que precaução devem ter as repetições HTTP?
Um timeout ou uma ligação fechada antes de receber resposta não demonstra que o envio não foi aceite. Uma vez que um envio pode não ser idempotente, não devem ser automatizadas repetições sem um identificador de idempotência, uma consulta de estado fiável ou evidência equivalente que evite duplicados.
Fontes consultadas
- SMPP Protocol Specification v3.4, Issue 1.2SMPP Developers Forum
- RFC 9110: HTTP SemanticsInternet Engineering Task Force (IETF) / RFC Editor
- 3GPP TS 23.040: Technical realization of the Short Message Service (SMS)3rd Generation Partnership Project (3GPP)
- Recommendation ITU-T E.164: The international public telecommunication numbering planInternational Telecommunication Union (ITU)