Caducidad y purga de colas A2P SMS: cómo evitar entregas tardías

Tres límites distintos: utilidad, cola interna y expiración del proveedor

La caducidad de mensajes SMS A2P no es un único temporizador. Conviene mantener separados tres controles: el deadline funcional que determina hasta cuándo el contenido sirve al destinatario; la política de expiración de la cola interna o broker; y el periodo de validez que se solicita al proveedor o al centro de servicio.

El TP-Validity-Period definido por 3GPP expresa durante cuánto tiempo el centro de servicio conserva el mensaje antes de completar la entrega. No equivale al TTL de la cola de la aplicación. Además, la implementación y el alcance de una opción de expiración de plataforma varían entre proveedores.

Por ejemplo, Twilio documenta un validity period para el tiempo que el mensaje permanece en su cola de salida. La propia documentación advierte que, una vez enviado a la red de carriers, el mensaje todavía podría quedar en cola y entregarse después. No se debe convertir ese parámetro en una garantía de entrega antes de una hora límite.

• Deadline funcional: ¿hasta cuándo tendría sentido que el destinatario recibiera este mensaje?
• TTL interno: ¿cuánto tiempo permite el broker mantenerlo disponible para procesamiento?
• Validez del proveedor: ¿qué etapa cubre el parámetro documentado por esa conexión?
• Confirma por escrito el significado, los límites y el comportamiento de cada parámetro en la documentación técnica aplicable.

Por qué una ruta recuperada puede liberar mensajes obsoletos

Cuando una conexión tiene capacidad limitada, algunas plataformas encolan solicitudes para enviarlas más adelante. Si la ruta vuelve a estar disponible, esos mensajes pueden reanudar su recorrido. El atasco, por sí solo, no invalida el contenido ni garantiza que el proveedor lo descarte.

Antes de despachar un elemento retenido, comprueba su deadline funcional. Si ya venció, no lo reenvíes solo porque la conexión haya recuperado capacidad. Una expiración de broker puede ayudar, pero su aplicación depende del producto y del estado del mensaje. Por ejemplo, Azure Service Bus documenta particularidades para mensajes expirados y mensajes que ya están bajo lock; no deben extrapolarse a otros brokers.

• Evalúa la vigencia funcional justo antes del envío, no únicamente al encolar.
• Al recuperar una ruta, procesa primero la verificación de vencimiento y después la selección de mensajes elegibles.
• Mide y alerta sobre la antigüedad de la cola; la latencia observada no sustituye una regla de caducidad.
• Verifica cómo trata tu broker los expirados, los mensajes bloqueados y los elementos de dead-letter.

Define políticas por clase de tráfico

Una duración única no sirve para todos los casos. La regla debe derivarse de la utilidad temporal del mensaje y de los requisitos aplicables, y traducirse en un deadline verificable. La expiración del proveedor y la caducidad interna deben configurarse por separado cuando la arquitectura lo permita.

Para OTP, NIST SP 800-63B-4 establece que una autenticación fuera de banda debe considerarse inválida si no se completa dentro de 10 minutos y que el secreto debe aceptarse una sola vez. OWASP también recomienda TTL corto, uso único, límites de intentos e invalidación tras una verificación exitosa. Ese límite de autenticación no es una duración universal para la cola ni una recomendación para otras clases de mensajes.

Las alertas transaccionales y los mensajes no urgentes requieren reglas propias. Define su caducidad según la operación que notifican, las expectativas del usuario y las obligaciones aplicables. Si no puedes justificar una duración concreta, no la presentes como estándar: documenta el criterio y valida el comportamiento.

• OTP: el sistema de autenticación debe rechazar el código vencido y evitar su reutilización, aunque el SMS llegue después.
• Alertas transaccionales: define qué evento las vuelve irrelevantes y cómo evitar una notificación atrasada que contradiga el estado actual.
• Mensajes no urgentes: establece una ventana funcional acorde con su propósito; no heredes automáticamente la configuración de OTP.
• En todas las categorías: conserva consentimiento y cumplimiento aplicables, y no reenvíes mensajes promocionales fuera de la autorización correspondiente.

Diseña el ciclo de vida y trata con cuidado los estados inciertos

Modela el recorrido como estados explícitos: encolado, elegible, enviado al proveedor, aceptado por el carrier, expirado, cancelado y cerrado con resultado incierto. Los nombres concretos varían; utiliza el contrato de tu plataforma y conserva la correspondencia con sus estados.

La aceptación de una solicitud no significa que el SMS ya se haya entregado. En la documentación de Twilio, por ejemplo, «sent» indica aceptación por el carrier upstream, mientras que «delivered» depende de una confirmación posterior. Un DLR o callback es una señal del sistema correspondiente, no una prueba independiente de recepción humana ni una garantía universal de confirmación del dispositivo.

Si no hay un resultado concluyente, conserva el estado como incierto hasta que llegue un evento posterior o se cierre la conciliación según una política documentada. Evita reintentos automáticos que puedan duplicar el mensaje sin evaluar el riesgo.

• Guarda el deadline funcional junto al identificador del mensaje y compruébalo en cada transición de procesamiento.
• Distingue solicitud aceptada, envío al carrier upstream y entrega informada; no los agrupes en un único estado de «éxito».
• Define qué evento cierra una operación y cómo se reconcilian los casos sin DLR o con estados contradictorios.
• Protege los OTP: no registres sus valores en claro como parte de la auditoría habitual.

Cambiar de ruta o purgar: qué hacer con mensajes en vuelo

Una purga interna puede impedir que mensajes aún controlados por tu sistema se procesen, pero no debe suponerse que puede retirar un SMS que ya pasó a la red. Las posibilidades de cancelación dependen del proveedor y del estado: la documentación de Twilio, por ejemplo, describe la cancelación de ciertos mensajes programados antes de su hora de envío; eso no establece una cancelación general después del despacho al carrier.

Al cambiar de ruta, separa los elementos que siguen en tu cola de los que el proveedor ya aceptó. Para los primeros, valida el deadline y decide si se retienen, se descartan o se reencaminan conforme a las reglas documentadas. Para los segundos, consulta estados y recibos, pero comunica el límite de control: el mensaje podría seguir avanzando aunque tu cola local se haya purgado.

En una purga amplia, delimita el alcance por identificador, clase de tráfico, ruta, intervalo temporal u otro criterio operativo verificable. Usa un modo de revisión previa si está disponible, y evita borrar indiscriminadamente elementos cuyo estado sea incierto.

• Detén o limita el despacho antes de cambiar las reglas, si el diseño operativo lo permite.
• Clasifica los mensajes como aún internos, entregados al proveedor o de resultado incierto.
• Cancela remotamente solo cuando el proveedor documente esa acción para el estado concreto.
• No afirmes que la purga impedirá la entrega de mensajes que ya fueron aceptados por la red.

Haz la purga auditable y conciliable

Una purga operativa debe poder reconstruirse: qué se retiró, por qué, bajo qué alcance y quién autorizó la acción. Guarda marcas de tiempo y los identificadores necesarios para relacionar la decisión local con los estados del proveedor y los recibos posteriores.

La auditoría no necesita almacenar el cuerpo del SMS para ser útil. En especial, evita registrar OTP en claro. Si el broker ofrece dead-lettering para expirados, puede servir para revisión y conciliación, pero es una capacidad que debe habilitarse y configurarse explícitamente; el comportamiento depende del broker.

• Registra motivo, alcance de la purga, actor o proceso autorizado y marcas de tiempo.
• Conserva identificadores de correlación y estado anterior y posterior, con acceso limitado.
• No incluyas rutinariamente contenido sensible ni secretos de autenticación en los registros.
• Documenta la retención, los permisos de purga y el procedimiento de conciliación de expirados o mensajes inciertos.

Prueba cada conexión y cada etapa antes de depender de la caducidad

El parámetro con el mismo nombre puede tener alcances distintos entre proveedores. Valida la documentación de la conexión concreta y realiza pruebas controladas en un entorno y con destinatarios autorizados. No conviertas un resultado puntual en garantía para otros operadores, rutas o estados de red.

Observa por separado el vencimiento de la cola interna, la solicitud de expiración al proveedor, los estados de aceptación y los recibos de entrega. Registra qué ocurrió con mensajes encolados, enviados y con resultado incierto. Repite las pruebas ante cambios relevantes de configuración o conexión, respetando los límites y condiciones del proveedor.

• Confirma unidades, rango permitido, valor predeterminado y etapa que cubre cada parámetro.
• Prueba mensajes que vencen antes del despacho y mensajes cuyo estado cambia durante la prueba.
• Compara el estado local con callbacks o recibos, y documenta los casos sin confirmación concluyente.
• Revisa las salvedades del broker y del proveedor; no generalices resultados de una plataforma.

Lista de comprobación operativa

Antes de activar o modificar una política, comprueba que el equipo puede identificar mensajes vencidos, distinguirlos de los que ya están en vuelo y explicar qué evidencia recibe de cada etapa. La revisión debe cubrir también permisos, alertas y comunicación entre operaciones, ingeniería y producto.

Cada clase de tráfico tiene un criterio funcional de caducidad documentado.

El consumidor comprueba el deadline antes de despachar, incluso tras una recuperación de ruta.

El TTL del broker y la expiración del proveedor están documentados como controles separados.

Los estados de aceptación, envío, entrega informada e incertidumbre no se confunden.

• La purga tiene alcance, motivo, autorización, marcas de tiempo e identificadores de conciliación.
• Hay alertas de antigüedad de cola, acumulación, vencimientos y falta de confirmación, con umbrales definidos por el equipo.
• Los cambios operativos se comunican a los equipos afectados y cuentan con un procedimiento de reversión.