Gestión de colas de salida A2P SMS: admisión, drenaje y recuperación
Una guía operativa para definir qué mensajes admite la cola, cómo clasificarlos ante fallos, cuándo caducan y cómo recuperar el flujo sin confundir aceptación aguas abajo con entrega al destinatario.
La cola empieza donde un sistema retiene el mensaje
En una cadena A2P pueden existir varias colas: en la aplicación emisora, en la plataforma de mensajería, en una conexión o intermediario y en sistemas posteriores. Para operar con claridad, identifica cuál es la cola que estás midiendo y quién es responsable de cada transición.
Un mensaje «en cola» todavía no equivale a un mensaje aceptado por el siguiente sistema, y la aceptación de ese sistema tampoco demuestra que haya llegado al teléfono. Define explícitamente la frontera de responsabilidad: por ejemplo, mensaje recibido por la plataforma, intento de envío, respuesta de aceptación del siguiente sistema y resultado posterior de entrega, si está disponible.
- Asigna a cada mensaje un identificador correlacionable a través de los sistemas que controlas.
- Registra cuándo entra en la cola, cuándo se intenta procesar y qué resultado devuelve el siguiente sistema.
- Mantén separados los estados internos y los estados comunicados por interfaces o informes externos.
Define estados que expliquen qué ocurrió
Un modelo interno útil permite distinguir el trabajo pendiente del que está siendo procesado y del que ya obtuvo una respuesta del sistema siguiente. También debe representar los mensajes diferidos, vencidos o apartados para revisión. Son categorías operativas: no deben presentarse como una lista de estados normativos SMPP ni confundirse automáticamente con códigos de una interfaz.
Documenta las transiciones permitidas, el evento que las provoca y el sistema que aporta la evidencia. Por ejemplo, una respuesta de aceptación aguas abajo puede cerrar la responsabilidad de la cola local, pero no debe etiquetarse como entrega final al destinatario salvo que exista evidencia apropiada para sostenerlo.
- Pendiente: admitido por la plataforma, aún sin intento activo.
- En proceso: un trabajador está gestionando el envío.
- Aceptado aguas abajo: el siguiente sistema confirmó que acepta el mensaje; no implica recepción en el terminal.
- Diferido: el procesamiento se pospone según una política definida.
- Vencido: la utilidad temporal del mensaje terminó y no debe enviarse como si siguiera vigente.
- En revisión: requiere una decisión operativa antes de reanudarlo o cerrarlo.
Admite tráfico de forma que proteja la capacidad
Una cola no debería crecer sin un límite operativo. Define límites de admisión y capacidad con relación a los recursos que realmente controlas: almacenamiento, trabajadores disponibles, conexiones y capacidad configurada para los destinos o clases de tráfico. No existe un umbral universal que pueda fijarse sin conocer la arquitectura, los acuerdos y el comportamiento observado.
Segmentar por destino o clase puede ayudar a evitar que un flujo con problemas ocupe todos los recursos de otros flujos. La segmentación también añade complejidad: define qué ocurre cuando se alcanza un límite, cómo se comunica el resultado al emisor y quién puede ajustar la política. Evita aceptar un mensaje si el sistema no puede conservarlo de manera fiable hasta procesarlo o rechazarlo claramente.
- Establece límites por cola y por los segmentos que tengan comportamiento o requisitos distintos.
- Define una acción explícita al alcanzar capacidad: rechazar, diferir o aplicar otra política documentada.
- Asegura que la aplicación emisora pueda distinguir una admisión de un rechazo y gestionar su propio reintento sin duplicar envíos.
- Revisa los límites con datos de entrada, salida, antigüedad y recursos, no con cifras genéricas.
Clasifica el fallo antes de reintentar
No todos los fallos justifican el mismo tratamiento. Una saturación temporal, una indisponibilidad, un rechazo que puede ser transitorio y un error que requiere corregir el mensaje o la configuración tienen implicaciones distintas. Usa la respuesta concreta de la interfaz o del sistema conectado y la documentación aplicable para clasificarla; no inventes una equivalencia entre códigos.
Para cada clase de fallo, documenta si el mensaje se reintenta, se difiere, se rechaza o pasa a revisión. Los reintentos deben estar acotados y coordinados entre emisor y plataforma: si ambos repiten el envío sin coordinación, pueden aumentar la carga y crear duplicados. Conserva el resultado original para facilitar el diagnóstico.
- Saturación: protege recursos y aplica la política de admisión o diferimiento definida.
- Indisponibilidad: determina si corresponde esperar y reintentar, con límites y registro del motivo.
- Rechazo potencialmente recuperable: confirma qué condición debe cambiar antes de volver a intentar.
- Error permanente o no corregible automáticamente: evita ciclos de reintento y deriva el caso a cierre o revisión.
- En todos los casos, registra la respuesta observada y la decisión aplicada.
Orden y prioridad sin inanición
FIFO —primero en entrar, primero en salir— es una opción sencilla cuando los mensajes de una cola comparten requisitos de urgencia y no hay una razón operativa para alterar el orden. Si hay clases con distinta vigencia o prioridad, una política explícita puede ser más adecuada, pero debe preservar la trazabilidad y evitar que el tráfico de menor prioridad quede bloqueado indefinidamente.
Antes de introducir prioridades, define qué mensajes pueden pertenecer a cada clase, quién determina esa clasificación y cómo se comprueba que la política funciona. No bases la prioridad en contenido sensible ni la uses para eludir controles de consentimiento o cumplimiento.
- Usa FIFO si el orden es un requisito y la clase es homogénea.
- Separa clases solo si existe una necesidad operativa justificada y verificable.
- Mide la espera por clase y revisa si una prioridad produce inanición en otras.
- Documenta el comportamiento ante mensajes con igual prioridad y ante cambios de clase.
Alinea la vigencia con la utilidad del mensaje
La vigencia expresa cuánto tiempo sigue siendo útil enviar un mensaje. Un código de un solo uso, una notificación transaccional y una campaña autorizada pueden tener necesidades temporales distintas; no asumas que comparten un plazo apropiado. El responsable del mensaje debe definir esa utilidad y la plataforma debe aplicar una política coherente con ella.
Cuando un mensaje vence, no lo envíes silenciosamente como si aún fuera válido. Registra la expiración y comunica el resultado de forma que el sistema emisor pueda decidir qué hacer. Si se considera un nuevo envío, debe tratarse como una nueva decisión de negocio, no como una repetición automática del contenido obsoleto.
- Define la vigencia por caso de uso con el responsable del mensaje.
- Comprueba la antigüedad antes de cada nuevo intento cuando la política lo requiera.
- Distingue expiración de rechazo o de entrega fallida.
- Evita reactivar automáticamente mensajes vencidos sin una decisión explícita.
Recupera el servicio con un drenaje controlado
Tras una interrupción, la recuperación no consiste solo en reanudar todos los envíos pendientes. Primero confirma que la causa de la acumulación está resuelta y que el siguiente sistema puede aceptar tráfico. Después libera trabajo gradualmente según la capacidad disponible, con límites de concurrencia definidos por la configuración y los acuerdos aplicables.
Durante el drenaje, vigila si vuelven a crecer la antigüedad o la profundidad de la cola, si aumentan los rechazos y si se mantienen los resultados esperados. Una cola que se reduce no es prueba suficiente de recuperación si los mensajes están expirando, rechazándose o pasando a revisión sin que el equipo lo advierta.
- Identifica y corrige la causa de la interrupción antes de acelerar el envío.
- Reanuda con límites controlados, no con una descarga ilimitada de mensajes acumulados.
- Verifica aceptación aguas abajo y resultados posteriores por separado.
- Mantén un procedimiento para pausar de nuevo si reaparece la acumulación o empeoran los resultados.
Observa la salud de la cola, no solo su tamaño
La profundidad indica cuántos mensajes esperan, pero por sí sola no explica si la situación mejora. Añade la antigüedad del mensaje más viejo, la tasa de entrada y la de salida, y los resultados agrupados por destino y clase. Interpreta estas métricas junto con los eventos de admisión, rechazo, diferimiento y expiración.
La aceptación del siguiente sistema debe presentarse como aceptación, no como entrega final. Si se reciben informes de entrega, su significado depende de la fuente y del nivel de verificación: un DLR recibido no equivale necesariamente a una recepción del terminal verificada de forma independiente. Documenta esa incertidumbre en paneles y reportes.
- Profundidad de cola y antigüedad del mensaje más viejo.
- Tasas de entrada y salida en intervalos coherentes con la operación.
- Aceptaciones, rechazos, diferimientos, expiraciones y mensajes enviados a revisión.
- Resultados desglosados por destino y clase, con definiciones consistentes.
- Alertas vinculadas a umbrales operativos propios, revisados con datos reales.
Preguntas frecuentes
¿Que un mensaje haya sido aceptado aguas abajo significa que se entregó?
No. Indica que el siguiente sistema aceptó el mensaje según la respuesta observada. No demuestra por sí solo que el teléfono lo haya recibido. Los informes de entrega también deben interpretarse según su origen y nivel de verificación.
¿Qué tamaño máximo debería tener una cola de salida?
No hay un valor universal aplicable a todas las plataformas. El límite depende de recursos, destinos, clases de tráfico, acuerdos y comportamiento observado. Defínelo con datos operativos y con una acción explícita cuando se alcance.
¿Conviene reintentar cualquier mensaje rechazado?
No. Primero identifica si la causa es temporal, corregible o permanente usando la respuesta y la documentación de la interfaz conectada. Limita los reintentos, evita que emisor y plataforma repitan sin coordinación y no reintentes automáticamente contenido vencido.
¿Debe usarse siempre FIFO?
FIFO es razonable cuando preservar el orden importa y los mensajes tienen requisitos parecidos. Si se necesitan prioridades, define clases y reglas explícitas y vigila que una clase no deje a otra esperando indefinidamente.
Fuentes consultadas
- SMPP v3.4, Issue 1.2SMPP Developers Forum
- HTTP Semantics (RFC 9110)IETF
- 3GPP specifications by series3GPP
- ITU-T Recommendation E.164International Telecommunication Union
- GSMA networks resourcesGSMA