Cómo enviar millones de SMS al día: guía de alto volumen
Envía millones de SMS al día: cálculo de TPS, binds y ventana SMPP, colas, limitación de velocidad, acuses DLR, ID de remitente, horarios y KPI de seguimiento.
Por OmniChannels.ai Editorial Team · Revisado por BroadNet Messaging Solutions Team
SMS y OTP
Respuesta breve
Para enviar millones de SMS al día, dimensiona el rendimiento para el pico y no para la media: divide los segmentos entre los segundos de tu ventana de envío, suma margen para los OTP y fija la ventana SMPP en al menos TPS por tiempo de ida y vuelta. Usa varios binds, colas por operador y un limitador que frene ante la saturación, procesa los acuses aparte y separa el tráfico OTP del promocional.
En esta página
- ¿Cuántos SMS por segundo necesitas para enviar millones al día?
- ¿Cómo planificar el rendimiento a partir de la hora punta y no de la media?
- ¿Qué es un bind SMPP y cuántos necesitas?
- ¿Cómo funciona la ventana SMPP?
- ¿Cómo encolar y limitar la velocidad a escala?
- ¿Cómo enrutar por operador a escala?
- ¿Cómo gestionar los acuses de entrega a escala?
- ¿Qué debes registrar en cada país antes de enviar?
- ¿Cómo respetar los horarios de silencio con volumen alto?
- ¿Por qué separar el tráfico OTP del promocional?
- ¿Qué KPI debes vigilar?
- ¿Cuál es la lista de comprobación para un envío de varios millones?
- Cómo ayuda OmniChannels.ai
Puntos clave
- Diez millones de mensajes al día suponen de media solo unos 116 por segundo, pero una promoción comprimida en cuatro horas exige unos 694 por segundo, y cada segmento adicional lo multiplica.
- La especificación SMPP permite emitir muchas peticiones sin esperar respuesta; el número de peticiones pendientes lo decide la implementación, por lo que la ventana debe pactarse y ajustarse. Una buena regla de partida es una ventana de al menos TPS por el tiempo de ida y vuelta en segundos.
- La saturación (ESME_RTHROTTLED, 0x58) y la cola llena (ESME_RMSGQFUL, 0x14) son señales para ir más despacio y reintentar con espera progresiva, no para reenviar de inmediato.
- Los acuses de entrega son un segundo flujo de alto volumen: planifica consumidores, almacenamiento y conciliación con el mismo cuidado que los envíos.
- La capacidad se pacta por cuenta y por ruta con tu proveedor; pide por escrito tus cifras de pico y pruébalas antes del lanzamiento.
Esta guía es para ingenieros, responsables de operaciones de mensajería y equipos de compras que envían, o van a enviar, entre uno y diez millones de SMS al día. Explica cómo convertir un volumen diario en un objetivo de rendimiento, cómo configurar binds y ventanas SMPP, cómo encolar y limitar la velocidad, cómo gestionar los acuses de entrega a escala y qué preparar en cada país. Las cifras de los ejemplos son números de planificación ilustrativos, no afirmaciones sobre la capacidad de ningún proveedor.
¿Cuántos SMS por segundo necesitas para enviar millones al día?
Necesitas el número de segmentos dividido entre los segundos de la ventana en la que realmente puedes enviar. El rendimiento, medido en TPS (mensajes o segmentos enviados por segundo), es una cifra de pico y no una media diaria. Consulta rendimiento (TPS).
Calcula primero la media y después el pico de tu ventana de envío real:
| Mensajes diarios | Media por segundo en 24 h | Si se envían en 4 horas | Si se envían en 2 horas |
|---|---|---|---|
| 1,000,000 | 11.6 | 69.4 | 138.9 |
| 5,000,000 | 57.9 | 347.2 | 694.4 |
| 10,000,000 | 115.7 | 694.4 | 1,388.9 |
Dos multiplicadores cambian la tabla:
- Segmentos. Un mensaje de más de un segmento se envía en varias partes, y la mayoría de las plataformas cuentan cada parte. 10 millones de mensajes con una media de 1.5 segmentos son 15 millones de envíos. Contrólalo con los límites de caracteres del SMS y el contador de caracteres.
- Margen. Suma el tráfico ajeno a la campaña, como los OTP, y un colchón para reintentos y operadores lentos. Un treinta por ciento es una holgura de planificación habitual, no una norma.
¿Cómo planificar el rendimiento a partir de la hora punta y no de la media?
Planifica a partir de la hora o la ventana con más tráfico, porque ahí se forman las colas y aparece la saturación. Usa esta fórmula:
TPS necesarios = (segmentos de la campaña ÷ segundos de la ventana + TPS de pico de OTP y alertas) × (1 + margen).
Ejemplo práctico: un comercio regional
Un comercio ficticio envía 6 millones de mensajes promocionales en un día a clientes del Golfo, con una media de 1.4 segmentos cada uno. Quiere terminar el envío en cuatro horas dentro de la franja diurna permitida.
- Segmentos: 6,000,000 × 1.4 = 8,400,000.
- Ventana: 4 horas = 14,400 segundos, así que 8,400,000 ÷ 14,400 = 583 por segundo.
- Tráfico pico de OTP y alertas durante la campaña: 40 por segundo (medición propia).
- Margen: 30 por ciento.
- Necesario: (583 + 40) × 1.3 ≈ 810 por segundo.
Esa es la cifra que el comercio pide a su proveedor que confirme por ruta, por escrito, antes del lanzamiento. Es un dato de planificación; no dice nada sobre lo que puede soportar ninguna plataforma.
¿Qué es un bind SMPP y cuántos necesitas?
Un bind SMPP es una sesión TCP de larga duración entre tu sistema y el SMSC del proveedor, autenticada con credenciales y una dirección IP permitida. SMPP (Short Message Peer-to-Peer) es el protocolo de telecomunicaciones para intercambiar SMS y está pensado para volumen sostenido. Consulta bind SMPP y SMPP frente a API REST.
Hay tres tipos de bind: transmisor (solo envío), receptor (solo acuses y mensajes entrantes) y transceptor (ambos en una sesión). La mayoría de los remitentes usan binds transceptor.
Cómo calcular cuántos binds necesitas:
- Toma los TPS de pico que necesitas.
- Divide entre el ritmo por bind que tu proveedor pacte para tu cuenta.
- Redondea hacia arriba y añade al menos un bind de reserva para que una conexión caída no detenga el envío.
- Pon el tráfico OTP en binds o en una cuenta propios.
Los binds se aprovisionan por cuenta, así que pide el número, el ritmo por bind y las IP de origen permitidas. Nuestra página de pasarela SMPP y la documentación SMPP para desarrolladores describen la conexión.
¿Cómo funciona la ventana SMPP?
La ventana es el número de peticiones submit_sm que puedes tener pendientes a la vez. SMPP es asíncrono: la especificación dice que un remitente puede enviar varias peticiones sin esperar las respuestas, y usa el sequence_number de cada PDU para asociar una respuesta con su petición. La especificación no define el máximo de operaciones pendientes; lo determina la implementación de cada lado.
La regla que se deduce de la aritmética de colas es:
Ventana ≥ TPS objetivo × tiempo de ida y vuelta (segundos).
| TPS objetivo | Ida y vuelta 50 ms | Ida y vuelta 150 ms | Ida y vuelta 300 ms |
|---|---|---|---|
| 100 | 5 | 15 | 30 |
| 400 | 20 | 60 | 120 |
| 810 | 41 | 122 | 243 |
Una ventana de 1 significa que el remitente espera cada respuesta, lo que limita el rendimiento a uno dividido entre el tiempo de ida y vuelta. Ampliar la ventana ayuda hasta alcanzar el ritmo que permite tu proveedor; a partir de ahí solo provocas saturación. Trata esa cifra como algo que se pacta con el proveedor y se prueba, no como algo que hay que maximizar. Reparte los TPS entre los binds cuando uses varios: cuatro binds con 810 TPS en total soportan cada uno unos 203.
¿Cómo encolar y limitar la velocidad a escala?
Coloca una cola duradera entre tu aplicación y la conexión SMPP y vacíala con un limitador de velocidad que puedas cambiar en ejecución. La cola absorbe los picos; el limitador te mantiene en el ritmo pactado.
- Cubo de tokens por bind y por ruta. Repón al TPS pactado; consume un token por cada submit_sm, contando cada segmento.
- Una cola por prioridad. Primero el tráfico de OTP y alertas, luego el transaccional y por último el promocional.
- Espera progresiva ante errores. Ante ESME_RTHROTTLED (0x58) o ESME_RMSGQFUL (0x14), haz una pausa y reintenta con espera exponencial y jitter. No reenvíes en un bucle cerrado.
- Reconecta con espera progresiva tras una desconexión y lleva el control de los números de secuencia pendientes para conciliar lo que se aceptó.
- Mantén vivas las sesiones. La especificación define un temporizador enquire_link para comprobar que el otro extremo sigue teniendo una sesión activa y un temporizador de inactividad tras el cual puede cerrarse la sesión. Envía enquire_link mientras no haya tráfico.
- Envíos idempotentes. Guarda tu propio ID de mensaje antes de enviar para que un reintento no pueda enviar dos veces.
¿Cómo enrutar por operador a escala?
Encola y limita la velocidad también por operador de destino, además de por bind, porque un operador lento no debe bloquear a los demás. Los operadores pueden limitar el tráfico A2P por remitente o por ruta, de modo que el límite efectivo de un país puede ser inferior al ritmo de la cuenta.
- Resuelve el operador de cada número. La consulta de numeración ayuda; consulta consulta HLR.
- Mantén una cola y un limitador por operador o por grupo de rutas.
- Vigila la tasa de entrega y el retraso de los acuses por operador, y frena a los que se degraden.
- Pregunta a tu proveedor si usa rutas directas; consulta rutas directas frente a rutas grises.
¿Cómo gestionar los acuses de entrega a escala?
Trata los acuses de entrega como un segundo flujo tan grande como el primero. Un acuse llega como un deliver_sm en tu bind y debes responder a cada uno con deliver_sm_resp. La especificación define estos estados finales e intermedios en el acuse: DELIVRD, EXPIRED, DELETED, UNDELIV, ACCEPTD, UNKNOWN y REJECTD. Consulta los acuses de entrega y los estados de entrega de mensajes explicados.
Un diseño fiable:
- Confirma rápido. Responde deliver_sm_resp en cuanto el acuse esté en una cola.
- Procesa de forma asíncrona con trabajadores que asocian el acuse al mensaje original por su ID.
- Haz el procesamiento idempotente. Los acuses pueden repetirse y es posible que lleguen desordenados.
- Gestiona los segmentos. Según la ruta, puedes recibir un acuse por parte o por mensaje; compruébalo con una prueba.
- Fija un tiempo límite para los mensajes que nunca reciben un estado final y márcalos como desconocidos.
- Mantén los consumidores de acuses fuera de la vía de envío para que una acumulación no frene el envío.
¿Qué debes registrar en cada país antes de enviar?
Las reglas del ID de remitente varían según el país y, en algunos mercados, los remitentes sin registrar se bloquean o se sustituyen. Ejemplos: Emiratos Árabes Unidos y Arabia Saudí exigen registro con los operadores, India exige el registro DLT del encabezado y de cada plantilla, y Estados Unidos usa 10DLC o números gratuitos en lugar de remitentes alfanuméricos. Los plazos van de unos pocos días laborables a cerca de un mes en los mercados que seguimos.
Empieza por los registros, porque están en la ruta crítica del lanzamiento. Consulta las normas de SMS marketing por país, el verificador de ID de remitente y la guía de ID de remitente para Emiratos Árabes Unidos y Arabia Saudí. Preparamos y presentamos contigo los registros a través de nuestro servicio de registros; las aprobaciones corresponden a los reguladores y a los operadores.
¿Cómo respetar los horarios de silencio con volumen alto?
Programa las promociones según la hora local de cada destinatario y la norma de cada país, y mantén el tráfico no promocional fuera de esa restricción. Algunos mercados publican franjas: Emiratos Árabes Unidos prohíbe los SMS comerciales de 21:00 a 07:00 y Arabia Saudí de 22:00 a 09:00 y de 01:00 a 12:00 durante el Ramadán. Consulta horas de silencio.
- Agrupa la lista por país y zona horaria antes de encolar.
- Libera cada grupo en su propia cola cuando se abra su franja.
- Detén las colas promocionales al final de la franja y traslada el resto al día siguiente.
- Planifica la secuencia con el planificador de horas de envío.
Una franja estrecha aumenta los TPS necesarios, así que compruébalo en la fórmula de planificación.
¿Por qué separar el tráfico OTP del promocional?
Los OTP y los mensajes de alerta son críticos en el tiempo y las campañas promocionales son masivas; si comparten cola o bind, una campaña puede retrasar un código de acceso. Usa binds o cuentas distintos, ID de remitente distintos cuando las normas lo exijan, colas separadas con prioridad estricta y seguimiento independiente. Los OTP no son promocionales, así que no les afectan los horarios de silencio. Protege también las rutas OTP frente al abuso: consulta la prevención del fraude por SMS pumping y la guía de OTP.
¿Qué KPI debes vigilar?
Vigila la salud de los envíos, la antigüedad de la cola, los resultados de los acuses y su retraso, desglosados por país y operador. Configura alertas ante cambios respecto a tu propia línea base.
| KPI | Fórmula | Qué te indica |
|---|---|---|
| Tasa de envíos aceptados | submit_sm_resp aceptados ÷ submit_sm enviados | Salud del bind y de la cuenta |
| Tasa de saturación | Respuestas ESME_RTHROTTLED ÷ submit_sm enviados | Ritmo o ventana demasiado altos |
| Antigüedad de la cola (p95) | Tiempo desde que entra en la cola hasta que se envía | Falta de capacidad |
| Tasa de entrega | DELIVRD ÷ mensajes con estado final | Calidad de ruta y de contenido |
| Proporción de fallidos y caducados | (UNDELIV + EXPIRED + REJECTD) ÷ estados finales | Validez de los números, ID de remitente, filtrado |
| Retraso del acuse (mediana y p95) | Hora del acuse − hora del envío | Lentitud del operador |
| Cobertura de acuses | Estados finales ÷ mensajes enviados | Acuses que faltan |
| Tasa de bajas | Respuestas STOP ÷ mensajes promocionales entregados | Ajuste de audiencia y contenido |
Consulta cómo mejorar la tasa de entrega de SMS para el diagnóstico.
¿Cuál es la lista de comprobación para un envío de varios millones?
- TPS de pico necesarios calculados a partir de los segmentos, la ventana y la carga de OTP.
- Ritmo por bind, número de binds, ventana e IP de origen confirmados por escrito por tu proveedor.
- ID de remitente registrados en cada país, con plantillas donde se exijan.
- Prueba de carga con una fracción del volumen y aumento por etapas; no empieces por el máximo.
- Colas, limitador, espera progresiva e idempotencia probados, incluida una desconexión forzada.
- Canal de acuses probado con el volumen completo de acuses.
- Programación de horarios de silencio verificada por país.
- Tráfico OTP separado y supervisado.
- Paneles y alertas activos, con un responsable de guardia.
- Un botón de parada que detenga al instante las colas promocionales.
Cómo ayuda OmniChannels.ai
BroadNet entrega SMS por conectividad directa con operadores y admite SMPP 3.4 sobre TLS con binds aprovisionados por cuenta, además de una API REST, envío masivo, SMS bidireccional, Unicode y árabe, consulta HLR e informes de entrega. La capacidad se dimensiona por cuenta y por ruta: cuéntanos tus destinos, tu volumen de pico, tus franjas de envío y tus ID de remitente, y pactamos contigo el rendimiento, los binds y los registros. Nuestro equipo prepara los registros de ID de remitente. Contacta con ventas con tu plan de volumen o consulta el programa mayorista.
Preguntas frecuentes
¿Cuántos SMS por segundo necesito para enviar un millón de mensajes?
Divide el número de segmentos entre los segundos de tu ventana de envío. Un millón de mensajes de un segmento en una hora requiere unos 278 por segundo, en cuatro horas unos 69 y repartidos en un día completo unos 12. En la mayoría de las plataformas los mensajes de varios segmentos cuentan una vez por segmento, así que un mensaje de dos segmentos duplica el ritmo necesario.
¿Qué es el tamaño de ventana SMPP y cómo se configura?
La ventana es el número de peticiones submit_sm que puedes tener pendientes, enviadas pero sin respuesta todavía. La especificación SMPP admite peticiones asíncronas pero deja el límite a la implementación. Una regla práctica es una ventana de al menos el TPS objetivo por el tiempo de ida y vuelta en segundos; súbela solo hasta el límite que acuerde tu proveedor, porque superarlo provoca saturación.
¿Cuántos binds SMPP necesito para un volumen alto?
Depende de tu ritmo de pico, del límite por bind que acuerde tu proveedor y de tus necesidades de redundancia. Divide el TPS de pico entre el ritmo pactado por bind, redondea hacia arriba y añade al menos uno de reserva para que una conexión caída no detenga el envío. Mantén el tráfico OTP en binds o cuentas propios. Los binds se aprovisionan por cuenta.
¿Qué hago cuando recibo ESME_RTHROTTLED?
Ve más despacio. La especificación define ESME_RTHROTTLED (0x58) como el remitente que supera los límites de mensajes permitidos. Pausa o reduce los envíos, reintenta los mensajes rechazados con espera exponencial y jitter, y nunca reintentes en un bucle cerrado, que alarga la saturación. Si ocurre con frecuencia, tu ventana o tu ritmo superan el límite pactado.
¿Cómo gestiono millones de acuses de entrega?
Confirma cada deliver_sm con deliver_sm_resp de inmediato, coloca el acuse en una cola y procésalo de forma asíncrona en un almacén indexado por ID de mensaje. Haz el procesamiento idempotente, porque los acuses pueden repetirse. Ejecuta los consumidores de acuses por separado de la vía de envío y vigila cuánto se retrasan.
¿Puedo enviar SMS promocionales por la noche?
En varios mercados no. Emiratos Árabes Unidos prohíbe los SMS comerciales de 21:00 a 07:00 y Arabia Saudí de 22:00 a 09:00, y de 01:00 a 12:00 durante el Ramadán. Programa las promociones según la hora local de cada destinatario y envía los OTP y las alertas por separado, ya que no son promocionales.
Fuentes
Siga leyendo
Más guíasSMS y OTP
SMS A2P mayorista: cómo elegir proveedor y probar rutas
SMS A2P mayorista: quién lo compra, cómo funcionan los binds SMPP, qué indican el DLR y la latencia de una ruta y qué controles de KYC y fraude exigir.
9 min de lectura
SMS y OTP
Qué es un SMS gateway: cómo funciona, tipos y cómo elegir
¿Qué es un SMS gateway? Cómo viaja un mensaje de su aplicación al móvil, los tipos (API, SMPP, email a SMS, módem GSM), funciones clave y cómo elegir uno.
10 min de lectura
Integración
Cómo elegir una API de mensajería: checklist para CTO
Cómo elegir una API de mensajería: checklist para CTO sobre canales, calidad de rutas, webhooks, seguridad, límites, reintentos, SMPP, MCP, cumplimiento y precios.
13 min de lectura
