Backpressure en A2P SMS: cómo diseñar colas que protejan la entrega ante picos, límites y degradaciones
Una guía operativa para separar la aceptación del envío A2P SMS, limitar la presión por destino y ruta, y gestionar esperas, caducidades y reintentos sin agravar una incidencia.
Qué significa backpressure en A2P SMS
El backpressure en A2P SMS es el conjunto de controles que evita que la entrada de solicitudes supere de forma sostenida la capacidad real de procesamiento y envío. Su objetivo no es aceptar el mayor número posible de peticiones, sino preservar el comportamiento útil del tráfico cuando existen picos, límites de tasa, congestión o degradación de una ruta.
Una respuesta positiva de una API no prueba que el mensaje haya llegado al terminal. En SMPP, submit_sm presenta un mensaje al Message Center para su entrega posterior; la solicitud de un recibo de entrega se configura por separado mediante registered_delivery. De forma similar, una plataforma puede aceptar y encolar un mensaje antes de enviarlo a un operador ascendente.
Si el sistema acepta más trabajo del que puede evacuar, la profundidad y la antigüedad de la cola aumentan. Para tráfico con plazo, el resultado puede ser peor que un rechazo explícito: un OTP puede salir tarde, un aviso transaccional puede perder utilidad y los reintentos pueden multiplicar mensajes o agravar la saturación.
- Trate la aceptación como un estado de admisión, no como evidencia de entrega.
- Mida la capacidad de salida efectiva por ámbito relevante, no solo la capacidad de entrada de la API.
- Aplique presión hacia arriba antes de que el trabajo acumulado supere el plazo útil del mensaje.
- Mantenga separados los estados internos de cola de los estados notificados por la red u operador.
Separe admisión, cola, planificación y confirmación de estado
Un diseño operable divide el ciclo de vida en capas con responsabilidades distintas. Esta separación permite decidir dónde aplicar límites y evita que un problema de entrega se oculte tras una API aparentemente sana.
La capa de admisión valida la solicitud, comprueba su clave de idempotencia, aplica cuotas y decide si se acepta, se difiere o se rechaza. La cola conserva el trabajo admitido con metadatos suficientes para priorizarlo, expirar mensajes y evitar duplicados. El planificador elige qué mensaje puede salir según la capacidad disponible. La capa de estado registra tanto transiciones internas como respuestas y DLR posteriores.
No conviene usar los DLR como señal principal de control en tiempo real. Los eventos generados por operadores pueden llegar mucho después del envío; por tanto, la salud inmediata debe basarse sobre todo en señales de admisión, cola, sesión y despacho.
- Admisión: autenticación, validación, clasificación, deduplicación y decisión de aceptar o rechazar.
- Cola: persistencia, prioridad, momento de creación, plazo útil, destino, ruta prevista e identificador idempotente.
- Planificación: selección de mensajes sujeta a límites jerárquicos y capacidad observada.
- Confirmación: registro de aceptación, encolado, intento de salida, respuesta técnica, expiración y DLR cuando exista.
Detecte la presión antes de que la cola se convierta en una incidencia
El indicador más evidente es una cola creciente, pero no es suficiente. Una cola puede permanecer estable y aun así ser inaceptable si los mensajes envejecen demasiado, si un destino consume la mayor parte de la capacidad o si los reintentos desplazan el tráfico nuevo.
Defina umbrales por clase de tráfico y por ámbito de control. El umbral útil para OTP no tiene por qué ser válido para un aviso transaccional no urgente, y un problema limitado a un destino o ruta no debería obligar a detener todo el tráfico.
La latencia de aceptación también merece seguimiento. Si la API empieza a tardar, puede estar acumulando trabajo antes de responder o depender de componentes que ya están degradados. Es preferible una admisión explícita y acotada a tiempos de respuesta crecientes e impredecibles.
- Profundidad de cola total y por cuenta, aplicación, destino, ruta, sesión y clase de tráfico.
- Antigüedad máxima y percentiles de antigüedad de mensajes aún no enviados.
- Tasa de admisión frente a tasa de despacho efectivo.
- Rechazos temporales, errores de sesión, tiempos de respuesta y reconexiones SMPP.
- Cantidad de mensajes que expiran internamente, se suprimen o se rechazan por política.
- Porcentaje de capacidad consumido por reintentos frente a primeros intentos.
Clasifique el tráfico antes de encolarlo
La prioridad debe asignarse antes de que el mensaje entre en una cola compartida. No basta con etiquetar todo como transaccional: hay mensajes con plazo estricto, otros con utilidad decreciente y otros que pueden esperar o no enviarse durante una degradación.
Una clasificación práctica distingue OTP, transaccional con plazo, marketing consentido y tráfico no prioritario. AWS diferencia los mensajes transaccionales, críticos o sensibles al tiempo, de los promocionales, que no lo son. Esa distinción es útil como punto de partida, pero cada organización debe documentar sus propias prioridades legítimas, obligaciones y plazos.
La clasificación no debe convertirse en un mecanismo para eludir reglas de ruta, consentimiento o remitente. La prioridad es una decisión operativa interna para usar capacidad limitada de forma coherente con la finalidad legítima del mensaje.
- OTP: mensajes de un solo uso con utilidad breve; deben tener presupuesto de espera corto y caducidad estricta.
- Transaccional con plazo: alertas, cambios de estado o avisos operativos que pierden valor después de un tiempo definido.
- Marketing consentido: tráfico que normalmente debe poder diferirse, limitarse o pausarse sin comprometer una operación crítica.
- No prioritario: tráfico de baja urgencia que debe ser el primero en reducirse o rechazarse bajo presión.
Defina presupuestos de espera y caducidad sin confundir estados
Cada clase de mensaje necesita un presupuesto de espera: el tiempo máximo que puede permanecer dentro de su propia plataforma antes de que deje de tener sentido intentar enviarlo. Ese presupuesto debe ser menor o igual que el plazo útil de negocio y debe revisarse frente a la capacidad de salida disponible.
La expiración interna es una decisión de su sistema: por ejemplo, suprimir un OTP que ha esperado más de lo permitido antes de asignarle una ruta. No debe comunicarse como un DLR del operador. Mantenga un estado explícito como “expirado internamente” o equivalente y conserve la causa de la decisión.
Cuando se use SMPP, validity_period expresa el momento de expiración en el SMSC tras el cual el mensaje debe descartarse si no se entregó. Este periodo de validez es distinto de la espera previa dentro de su propia cola y también distinto de una confirmación de entrega al terminal. En servicios de mensajería, el TTL controla cuánto se intenta entregar un SMS, no una garantía de que se recibirá un DLR final.
- Guarde por mensaje: momento de creación, fecha límite interna, periodo de validez solicitado y motivo de expiración si se produce.
- No programe salida para mensajes cuyo presupuesto interno ya se agotó.
- Exponga por separado: expirado antes de enviar, expirado durante el intento de entrega y DLR recibido cuando aplique.
- No interprete una expiración ni un estado de aceptación como confirmación de recepción en el terminal.
Aplique límites jerárquicos y controle las ráfagas
La capacidad no es una cifra única. Un sistema puede tener capacidad agregada suficiente y, aun así, estar limitado para una cuenta, una aplicación, un destino, una ruta, una sesión SMPP o un proveedor. Los límites deben poder componerse: un mensaje solo sale si dispone de presupuesto en todos los ámbitos que correspondan.
Un modelo de token bucket es útil para aplicar una tasa sostenida y limitar la ráfaga después de una acumulación. La tasa limita el despacho continuo; el tamaño de ráfaga limita la velocidad con la que una cola acumulada puede vaciarse. Esto evita que la recuperación tras un corte breve cause una nueva congestión.
Aplique el mismo límite de despacho a primeros intentos y reintentos. Si los reintentos quedan fuera de control, consumen capacidad que debería reservarse para tráfico nuevo o prioritario.
- Límite por cuenta, campaña o aplicación para proteger cuotas y aislamiento entre clientes.
- Límite por destino para evitar que una numeración, red o país absorba capacidad compartida.
- Límite por ruta y proveedor para respetar la capacidad o restricción aplicable.
- Límite por sesión SMPP para no sobrecargar una conexión o su ventana operativa.
- Reserva o ponderación por clase de tráfico para proteger OTP y otros flujos con plazo.
- Control de ráfaga para recuperar de forma gradual después de una pausa o degradación.
Elija una estrategia de admisión explícita
Cuando no existe capacidad suficiente, hay cuatro resultados legítimos: aceptar, diferir, rechazar o pedir al emisor que reduzca su ritmo. La elección debe depender del plazo útil, de la prioridad documentada, de la posibilidad de reintento seguro y de si la falta de capacidad es global o localizada.
Aceptar significa que el mensaje entra en la cola dentro de un presupuesto de espera realista. Diferir significa conservarlo para una ventana posterior solo si aún tendrá utilidad. Rechazar es apropiado cuando no hay posibilidad razonable de cumplir el plazo o cuando la política no permite acumular más trabajo. Solicitar reducción de ritmo es especialmente útil para integraciones que pueden adaptar su producción.
En HTTP, una sobrecarga temporal puede comunicarse con 503 y Retry-After. Es preferible que el cliente reciba una señal explícita y accionable a aceptar indefinidamente solicitudes que probablemente caducarán. Para que esa integración sea segura, documente claramente la semántica de reintento y las claves de idempotencia.
- Acepte solo si la cola y la capacidad sugieren que el mensaje puede salir dentro de su presupuesto.
- Difiera tráfico tolerante a espera, con una fecha límite que impida su envío tardío.
- Rechace OTP o mensajes con plazo agotado o inviable, con una causa legible por máquina y por operación.
- Devuelva una indicación de reducción temporal de ritmo cuando la interfaz lo permita.
- No convierta un rechazo de admisión en una aceptación silenciosa que termina en una cola sin límite.
Planifique la cola con justicia y prioridades documentadas
La planificación debe evitar que un único cliente, campaña o destino consuma toda la capacidad disponible. Al mismo tiempo, no debe alterar de forma opaca prioridades legítimas de negocio, como la protección de OTP frente a marketing consentido durante una restricción.
Una combinación razonable es usar colas por clase de tráfico y aplicar límites por inquilino, destino y ruta antes de seleccionar el siguiente mensaje. Dentro de una misma clase, una política de reparto justo puede impedir que una fuente muy activa monopolice el despacho.
El orden estricto de llegada no siempre es el orden correcto. En presencia de plazos, puede ser preferible priorizar mensajes cercanos a caducar dentro de una clase, siempre que la política evite inanición de los demás mensajes. Cualquier excepción debe ser explícita, auditable y coherente con la finalidad del tráfico.
- Evite una única cola global sin metadatos de prioridad, destino y fecha límite.
- Aísle destinos o rutas degradadas para que no bloqueen tráfico saludable.
- Use cuotas o reparto justo dentro de categorías equivalentes.
- Proteja prioridades documentadas sin etiquetar indebidamente tráfico no urgente como crítico.
- Revise periódicamente si hay mensajes que nunca reciben turno de despacho.
Preguntas frecuentes
¿Aceptar un SMS por API significa que ya se ha entregado?
No. La aceptación indica que la solicitud fue admitida o encolada. En SMPP, submit_sm presenta el mensaje para entrega posterior. La entrega y los recibos de entrega son etapas separadas, y un DLR, cuando se recibe, tampoco debe confundirse con una garantía universal e inmediata.
¿Cuándo conviene rechazar un OTP en vez de encolarlo?
Conviene rechazarlo de forma explícita cuando la capacidad disponible y la antigüedad de la cola indican que no podrá salir dentro de su plazo útil. Enviar un OTP tarde puede ser menos útil que informar al emisor para que aplique su flujo de recuperación o genere un nuevo código.
¿Los reintentos deben tener un límite de tasa separado?
Deben estar sujetos al mismo control de despacho que los primeros intentos y, además, tener límites de número de intentos y tiempo. Si se excluyen del límite, pueden consumir la capacidad disponible y prolongar una congestión.
¿Un validity_period de SMPP sustituye una caducidad interna?
No. validity_period define la expiración en el SMSC después de la cual el mensaje debe descartarse si no se entregó. La plataforma sigue necesitando un presupuesto de espera interno para impedir que mensajes sin utilidad lleguen tarde al SMSC.
¿Se deben usar los DLR para detectar una degradación en tiempo real?
No como señal única. Los eventos procedentes de operadores pueden llegar con retraso considerable. Para control operativo inmediato, supervise admisión, profundidad y antigüedad de cola, despacho, errores técnicos, salud de sesiones y comportamiento por destino o ruta.
¿Cómo se evitan duplicados cuando el cliente reintenta una petición HTTP?
Use una clave de idempotencia persistente o un mecanismo equivalente que permita reconocer una solicitud ya aplicada. Los reintentos automáticos de operaciones no idempotentes son inseguros si el emisor no puede saber si la solicitud original se procesó.
Fuentes consultadas
- SMPP Protocol Specification v3.4, Issue 1.2SMPP Developers Forum
- RFC 9110: HTTP SemanticsIETF
- Cloud Tasks: Configure queue routing, limits, and retriesGoogle Cloud
- Cloud Tasks v2 API reference: RateLimitsGoogle Cloud
- AWS End User Messaging SMS: How SMS worksAmazon Web Services
- AWS End User Messaging SMS: Event types for SMS, MMS, and voiceAmazon Web Services
- AWS End User Messaging SMS: Example of sending an SMS or voice messageAmazon Web Services
- Messages resourceTwilio
- Outbound Message Status in Status CallbacksTwilio
- 30036: Validity Period ExpiredTwilio
- 30001: Queue overflowTwilio