Cómo dimensionar TPS, colas y capacidad para picos de tráfico A2P SMS
Guía operativa para calcular TPS, dimensionar colas, separar prioridades y probar la capacidad de envío A2P SMS sin confundir aceptación, DLR y recepción final.
La pregunta operativa: cuántos TPS necesita realmente una operación A2P SMS
Dimensionar TPS no consiste en elegir una cifra única para toda la plataforma. La pregunta útil es: ¿cuántos mensajes deben ser aceptados, procesados y enviados dentro de una ventana operativa concreta, para una mezcla concreta de destinos y clases de tráfico?
El TPS requerido debe derivarse del volumen previsto y de la ventana objetivo. Como punto de partida: TPS base = mensajes previstos / segundos de la ventana. Esta fórmula sirve para planificar, no constituye una garantía de capacidad de una API HTTP, una sesión SMPP, un proveedor, una ruta o una red móvil.
La cifra resultante debe documentarse junto con sus supuestos: distribución temporal, mezcla de destinos, prioridad del tráfico, política de reintentos, expiraciones y límites confirmados para cada conexión o ruta. Sin esos supuestos, un TPS agregado puede ocultar un cuello de botella relevante.
- Defina qué significa “dentro de la ventana”: aceptación interna, aceptación del proveedor o estado final comunicado.
- Calcule por clase de tráfico y por destino, no solo para el total agregado.
- Trate el margen como una decisión explícita para ráfagas, reintentos y variación de rutas; no como una garantía implícita.
- Valide los límites efectivos con el proveedor u operador que gestiona cada capacidad.
Definir el pico: volumen, ventana, distribución temporal y destinos
El volumen diario o mensual no dimensiona un pico. Dos operaciones con el mismo volumen pueden requerir capacidades muy diferentes si una reparte los envíos durante horas y la otra debe emitirlos en minutos. La unidad de análisis debe ser el perfil temporal del evento, preferiblemente por minuto y, cuando el caso lo requiera, por segundo.
También es importante separar los destinos. Un volumen concentrado en un país, red, rango de numeración, remitente o ruta puede alcanzar límites antes que el total de la plataforma. Los números de destino deben gestionarse con una normalización coherente con el plan internacional E.164 y con las reglas de direccionamiento aplicables a la integración.
Los picos de autenticación suelen estar ligados a acciones simultáneas de usuarios o a incidentes de acceso. Las campañas pueden sincronizarse por una hora de lanzamiento. Ambos casos requieren un perfil de llegada realista, no una media diaria.
- Mensajes previstos por intervalo de tiempo.
- Ventana objetivo por clase de tráfico.
- Distribución por país, red, ruta y remitente.
- Porcentaje esperado de OTP, transaccional y campaña.
- Eventos que puedan producir ráfagas: aperturas, lanzamientos, recuperación de acceso o procesos por lotes.
- Reintentos previstos y condiciones que los activan.
Distinguir cuatro límites de capacidad
Una respuesta de aceptación de la interfaz no demuestra que el mensaje haya completado el recorrido hacia el destinatario. Para operar con precisión, separe al menos cuatro etapas: aceptación de API HTTP o SMPP, procesamiento y cola internos, aceptación o procesamiento por el proveedor, y estado final comunicado por la cadena SMS.
En SMPP, submit_sm y submit_sm_resp reflejan el intercambio entre el ESME y el SMSC. El resultado posterior puede comunicarse mediante un SMSC Delivery Receipt cuando se ha solicitado. Por tanto, el TPS de submit_sm aceptados no debe presentarse como TPS entregados ni como prueba de recepción en terminal.
Esta separación también mejora el diagnóstico. Si la aceptación local permanece estable pero crece la cola interna, el límite está antes de la salida. Si las solicitudes pendientes aumentan o las respuestas se degradan, el problema puede estar en la conexión o en el extremo remoto. Si el estado final cambia por destino, la lectura debe hacerse por ruta y red, no solo como promedio global.
- Límite de aceptación: peticiones que la interfaz admite.
- Límite de procesamiento: capacidad para validar, encolar, priorizar y despachar.
- Límite de proveedor o ruta: capacidad técnica y contractual confirmada para cada destino.
- Comportamiento de red: estados y tiempos finales que pueden variar por la cadena de entrega.
Cálculo base de TPS y margen documentado
El cálculo inicial es directo: divida el número de mensajes que deben procesarse por los segundos disponibles. Por ejemplo, si una operación debe aceptar y despachar un lote dentro de una ventana determinada, el TPS base representa la tasa media mínima para esa ventana. Después, contraste esa tasa con el perfil temporal: si la llegada se concentra al inicio, la tasa de entrada puede superar ampliamente la media.
El margen no debe elegirse como una cifra universal. Debe responder a una hipótesis concreta: una ráfaga inicial, una recuperación de sesión, un incremento temporal de solicitudes, una redistribución de destinos o reintentos controlados. Es preferible registrar varios escenarios —esperado, alto y de contingencia— que ocultar todos los riesgos bajo un único multiplicador.
El cálculo debe repetirse por partición operativa. Una plataforma puede disponer de capacidad agregada suficiente y, aun así, no disponer de la capacidad necesaria para un destino o una ruta concreta.
- TPS base = mensajes previstos / segundos de la ventana.
- Calcule TPS de entrada y TPS de salida por separado.
- Añada margen solo con una causa operativa identificada.
- Compare el resultado con límites por ruta, destino, conexión y clase de tráfico.
- Revise el cálculo cuando cambien el perfil de destinos, la ventana o la política de reintento.
Por qué el promedio engaña
Una media suaviza exactamente el comportamiento que causa incidentes. Si miles de solicitudes llegan a la vez, una tasa media diaria no explica la profundidad de cola necesaria ni la antigüedad que alcanzarán los mensajes. El diseño debe considerar la diferencia entre la tasa de llegada y la tasa sostenible de salida en cada intervalo.
La concentración por destino también importa. El envío a múltiples destinos no equivale a enviar el mismo volumen a una única red. Los límites concretos no están normalizados por SMPP ni por HTTP: deben conocerse mediante la documentación aplicable, los acuerdos operativos y la observación de la ruta real.
Para OTP, además, una espera prolongada puede convertir un mensaje técnicamente procesable en un mensaje inútil. Por ello, un pico no se gestiona solo aumentando la cola; exige decidir qué tráfico se admite, cuál se retrasa y cuál debe expirar de forma controlada.
- Analice máximos por segundo o minuto, no solo medias.
- Mida la concentración por destino, ruta, remitente y tipo de tráfico.
- Modele la llegada inicial de campañas y eventos de autenticación.
- Defina el punto a partir del cual cada clase de mensaje deja de ser útil.
Dimensionar colas: profundidad, antigüedad y expiración
La profundidad de cola requerida depende del exceso temporal de entrada sobre la salida sostenible. Una aproximación operativa es calcular el máximo acumulado de la diferencia entre tasa de entrada y tasa de servicio durante el pico. Si entran más mensajes de los que pueden salir, el diferencial se acumula; cuando la salida vuelve a superar la entrada, la cola se drena.
La profundidad por sí sola no es suficiente. Fije una antigüedad máxima admisible por clase de tráfico. Una cola puede contener todos los mensajes y seguir incumpliendo la utilidad de un OTP o de una notificación transaccional sensible al tiempo. La antigüedad debe medirse desde un timestamp definido y consistente, por ejemplo, desde la aceptación de la solicitud por la plataforma.
SMPP permite indicar un validity_period, que representa una hora de expiración en el SMSC tras la cual el mensaje debe descartarse si no se ha entregado. Esta capacidad no sustituye una caducidad funcional propia de la aplicación: la plataforma debe evitar que un mensaje sin valor permanezca innecesariamente en colas internas o compita con tráfico crítico.
- Calcule la acumulación máxima prevista durante el pico.
- Establezca un límite de antigüedad para cada clase de tráfico.
- Defina qué ocurre al superar la antigüedad: cancelar, expirar o informar al sistema originador.
- Alinee la expiración interna con el validity_period y con las reglas del proveedor cuando corresponda.
- Mida profundidad y antigüedad por cola, destino y prioridad.
Separar OTP, mensajes transaccionales y campañas
OTP, tráfico transaccional y campañas no deberían compartir una única cola sin controles. La clasificación es una decisión de producto y operación, pero debe traducirse en políticas explícitas de admisión, prioridad, reserva de capacidad, expiración y degradación.
Los OTP suelen requerir una antigüedad funcional muy corta. Los mensajes transaccionales pueden tener una tolerancia distinta según el proceso de negocio. Las campañas legítimas y consentidas, en cambio, suelen ser candidatas a una programación más flexible cuando la capacidad está tensionada. La política debe ser conocida por producto, operaciones y los sistemas que originan los mensajes.
SMPP incluye priority_flag y campos relacionados con el servicio, pero el estándar no prescribe una política de colas ni garantiza que una marca de prioridad produzca el mismo resultado en todas las implementaciones. La prioridad debe aplicarse principalmente en la propia plataforma y coordinarse con las condiciones de la ruta.
- Reserve capacidad o admisión para tráfico crítico cuando sea necesario.
- Evite que una campaña consuma la cola o la capacidad destinada a OTP.
- Asigne antigüedad máxima y acción de expiración por clase.
- Registre la razón de cada degradación para análisis posterior.
- Mantenga los envíos legítimos, consentidos y sujetos a las reglas aplicables.
Presupuestos de latencia y semántica de los DLR
Un presupuesto de latencia útil divide el recorrido en etapas observables: tiempo hasta la aceptación de API o SMPP, espera en cola propia, tiempo hasta la aceptación o procesamiento del proveedor y tiempo hasta el estado final comunicado. Cada etapa debe tener su timestamp, fuente y método de correlación.
No equipare la respuesta inicial con la recepción final. En SMPP, la respuesta a submit_sm confirma el intercambio de la solicitud con el SMSC, mientras que el resultado posterior se comunica mediante un delivery receipt cuando se solicita. Los estados pueden incluir, entre otros, DELIVRD, EXPIRED, UNDELIV y REJECTD.
Tampoco todos los informes de entrega tienen la misma semántica. 3GPP distingue informes emitidos por el Service Centre de los emitidos por la estación móvil. Por ello, un DLR emitido por un SMSC o por una red intermedia debe etiquetarse por su emisor y significado. No debe presentarse automáticamente como evidencia independiente de recepción en el terminal.
- Mida latencia por etapa, no solo un tiempo total.
- Use percentiles para identificar colas largas y degradación de cola.
- Conserve la fuente del estado: plataforma, proveedor, SMSC u otra parte de la cadena.
- Diferencie aceptación, estado final comunicado y recepción en terminal cuando exista evidencia de esa naturaleza.
- Evite promesas de recepción final basadas únicamente en una respuesta inicial o en un DLR de semántica no confirmada.
Preguntas frecuentes
¿Cómo se calcula el TPS necesario para A2P SMS?
Como punto de partida, divida los mensajes previstos entre los segundos de la ventana objetivo. Después calcule por destino, ruta, conexión y clase de tráfico, y documente por separado el margen para ráfagas, reintentos y variación operativa. El resultado es una necesidad de planificación, no una garantía de capacidad de red.
¿Un submit_sm_resp exitoso significa que el SMS llegó al móvil?
No. submit_sm_resp refleja la respuesta a la solicitud SMPP entre el ESME y el SMSC. El resultado posterior requiere observar el delivery receipt cuando se haya solicitado y analizar su estado y semántica. Un DLR emitido por un SMSC no demuestra automáticamente recepción en terminal.
¿Cómo se calcula el tamaño de una cola SMS?
Estime el máximo acumulado durante los intervalos en que la tasa de llegada supera la tasa sostenible de salida. Además de la profundidad, defina una antigüedad máxima por clase de tráfico y la acción al superarla, como expiración o cancelación controlada.
¿Por qué debo separar OTP y campañas?
Porque sus requisitos de utilidad y espera son distintos. Una campaña puede programarse o reducirse cuando existe presión de capacidad, mientras que un OTP suele perder valor si espera demasiado. Las políticas deben separar admisión, prioridad, antigüedad y degradación.
¿Cómo influye SMPP en el dimensionamiento de concurrencia?
SMPP permite solicitudes asíncronas y usa sequence_number para correlacionar solicitudes y respuestas. Una aproximación útil es estimar solicitudes en vuelo como TPS objetivo multiplicado por la latencia observada de submit_sm_resp. El límite final debe ajustarse por sesión según documentación, errores, timeouts y comportamiento observado del proveedor.
¿Qué precaución deben tener los reintentos HTTP?
Un timeout o una conexión cerrada antes de recibir respuesta no demuestra que el envío no haya sido aceptado. Dado que un envío puede ser no idempotente, no deben automatizarse reintentos sin un identificador de idempotencia, una consulta fiable de estado o evidencia equivalente que evite duplicados.
Fuentes 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)