Deduplicación en A2P SMS: cómo evitar mensajes repetidos sin bloquear notificaciones legítimas

Qué problema resuelve la deduplicación y qué no debe hacer

La deduplicación de mensajes A2P SMS reduce envíos repetidos que proceden de solicitudes duplicadas, reintentos de red, eventos concurrentes o incertidumbre tras una respuesta incompleta de una API. Su objetivo no es impedir toda repetición: debe evitar que una misma intención de negocio produzca varios SMS no deseados, sin bloquear un reenvío legítimo, una alerta nueva o una comunicación consentida que tenga un propósito distinto.

El principio técnico es la idempotencia. Una operación idempotente mantiene el mismo efecto previsto aunque se procese una o varias veces. En mensajería, esto exige que la aplicación pueda reconocer que dos solicitudes representan la misma intención antes de crear dos envíos independientes.

Una desconexión antes de recibir la respuesta de la plataforma no demuestra que el envío no se haya creado. En ese caso, crear otro mensaje sin reconciliar el estado puede causar un duplicado. La política debe conservar un identificador idempotente propio, persistirlo y usarlo para consultar o reconciliar el resultado antes de emitir un segundo envío.

• No trate la deduplicación como un bloqueo global por número de teléfono.
• No asuma que un acuse de API, un estado en cola o un evento de envío confirma la recepción en el terminal.
• Aplique la decisión sobre la intención de negocio y el estado del ciclo de vida, no solo sobre el texto del SMS.
• Defina excepciones explícitas y auditables para reenvíos solicitados, cambios materiales de contenido o incidentes.

Los tres casos que deben separarse

Una política útil empieza por clasificar el motivo de la repetición. Los tres casos pueden parecer iguales en el historial de un destinatario, pero requieren decisiones diferentes.

El duplicado técnico ocurre cuando la misma intención se procesa más de una vez: por ejemplo, dos solicitudes concurrentes con la misma clave, un reintento después de perder la respuesta o la repetición de un evento desde una cola. Normalmente debe suprimirse si existe un envío activo o ya creado para la misma intención.

El reintento controlado es una acción deliberada dentro de una política definida. Puede ser necesario cuando el estado anterior indica fallo, no entrega o resultado incierto, pero debe usar la misma correlación de negocio, límites de frecuencia y reglas de elegibilidad. No debe confundirse con volver a ejecutar ciegamente una petición.

Un mensaje legítimamente repetido corresponde a un nuevo propósito, evento, desafío o autorización. Una confirmación de pedido y una alerta posterior sobre una modificación del pedido pueden dirigirse al mismo número y tener texto parecido, pero no son el mismo evento de negocio.

• Duplicado técnico: misma intención, misma clave, repetición no deseada.
• Reintento controlado: misma intención, nueva acción permitida por una regla de estado y tiempo.
• Repetición legítima: nueva intención o cambio material verificable.

Diseñe una clave de deduplicación basada en la intención

La clave debe representar una unidad concreta de intención de negocio. El número de destino es necesario, pero no suficiente. Debe almacenarse y compararse en una representación internacional normalizada conforme al plan E.164, evitando que diferencias de formato local, espacios, guiones o prefijos produzcan claves distintas para el mismo destino.

Como base, una clave puede combinar destino normalizado, propósito, identificador del evento de negocio, remitente o perfil de envío y un identificador de correlación. La plantilla o su versión puede añadirse cuando ayude a distinguir comunicaciones materialmente diferentes. En sistemas distribuidos, conviene guardar también una clave idempotente generada por la aplicación y estable durante los reintentos de esa misma operación.

No use el cuerpo del SMS como única clave. Los mensajes dinámicos cambian por importes, fechas, nombres o referencias. En autenticación, el texto puede contener secretos distintos para la misma transacción o mensajes parecidos para desafíos diferentes. Dos OTP con apariencia similar no deben considerarse equivalentes sin conocer el desafío, intento o evento de autenticación al que pertenecen.

• Destino normalizado en formato internacional.
• Propósito: autenticación, alerta, confirmación, campaña u otro dominio definido.
• Identificador de evento: pedido, incidencia, sesión, desafío o transacción.
• Remitente o perfil de envío, cuando forme parte de la intención.
• Versión de plantilla o clasificación de contenido, si es relevante.
• Identificador de correlación e idempotencia persistente.

Aplique ventanas temporales por caso de uso, no una ventana universal

La ventana de deduplicación es el período durante el que dos solicitudes con la misma intención se consideran candidatas a supresión o reconciliación. No existe una duración universal correcta: debe definirse por propósito, riesgo, experiencia de usuario y ciclo de vida esperado del mensaje.

En OTP y otros secretos de autenticación, la política debe estar ligada a la transacción de autenticación y al secreto específico. Un secreto debe aceptarse una sola vez durante su vigencia. NIST establece que una autenticación fuera de banda debe considerarse no válida si no se completa dentro de 10 minutos; ese límite no obliga a que la ventana operativa de supresión sea de 10 minutos, pero evita tratar la autenticación como un proceso abierto indefinidamente.

Para alertas transaccionales, confirmaciones y comunicaciones consentidas, la ventana debe reflejar el evento. Una confirmación repetida del mismo pedido puede suprimirse mientras el mismo evento y versión estén pendientes o ya procesados. Sin embargo, una actualización material del pedido, una nueva incidencia o una petición verificable de reenvío debe evaluarse como una nueva condición, no como un duplicado automático.

• OTP: vincule la decisión al desafío y al secreto, no solo al destinatario o al texto.
• Alertas: use el identificador de incidencia, estado o evento que originó la notificación.
• Confirmaciones: diferencie la primera confirmación de una modificación posterior del mismo proceso.
• Campañas consentidas: separe eventos y reglas de frecuencia de la deduplicación técnica.

Use estados de decisión y una máquina de estados

Una deduplicación segura no se limita a devolver sí o no. Conviene usar estados de decisión explícitos: permitir, suprimir, poner en revisión y reemplazar un mensaje pendiente. Cada estado debe estar respaldado por una máquina de estados que diferencie, como mínimo, solicitudes nuevas, mensajes pendientes de envío, enviados, entregados, no entregados, fallidos y de resultado desconocido.

Permitir significa que no existe una coincidencia equivalente dentro de la política aplicable o que una excepción autorizada convierte la solicitud en una nueva intención. Suprimir significa que ya existe una operación equivalente cuyo efecto debe conservarse. Revisar se reserva para conflictos de datos, excepciones de alto riesgo o resultados ambiguos que no deben resolverse mediante una regla automática.

Reemplazar pendiente puede utilizarse únicamente cuando la política permite sustituir un mensaje que todavía no ha salido del estado pendiente y la plataforma o arquitectura controla de forma fiable dicha transición. No debe asumirse que un mensaje ya enviado, ni siquiera uno marcado como enviado por un proveedor, puede retirarse o reemplazarse.

• Permitir: nueva intención o excepción válida.
• Suprimir: misma intención dentro de la ventana y con estado que impide otro envío.
• Revisar: conflicto de correlación, datos incompletos o excepción de riesgo.
• Reemplazar pendiente: solo antes del envío efectivo y con control del estado.

Resuelva concurrencia, incertidumbre y callbacks asíncronos

Dos solicitudes idénticas pueden llegar al mismo tiempo desde procesos diferentes. La protección debe producirse antes de crear dos mensajes: use una reserva atómica o una restricción de unicidad sobre la clave de deduplicación y la ventana aplicable. La operación debe devolver la decisión y la referencia al registro existente cuando corresponda.

Cuando una respuesta de la API se pierde o llega una desconexión, mantenga el resultado como incierto. Antes de volver a enviar, consulte o reconcilie por la clave idempotente, el identificador de correlación o el identificador externo disponible. Si no puede determinarse el resultado, aplique una regla de riesgo documentada en lugar de asumir que el primer intento falló.

Los callbacks de estado son eventos asíncronos de ciclo de vida. Pueden llegar tarde o en un orden diferente al esperado. Deben validarse de acuerdo con el mecanismo ofrecido por la plataforma y procesarse de forma tolerante a cambios en parámetros y secuencias. Un estado en cola indica aceptación para procesamiento; un estado enviado tampoco es una confirmación uniforme de entrega al terminal. Incluso un DLR de entrega debe interpretarse según la semántica contractual y técnica de la ruta, sin presentarlo como prueba independiente de lectura por el usuario.

• Reserve la clave antes de crear el envío para evitar carreras.
• Conserve el estado desconocido cuando la respuesta sea incierta.
• Haga idempotente el procesamiento de callbacks.
• No rebaje estados terminales con eventos retrasados o reordenados sin una regla explícita.
• Diferencie aceptación de API, procesamiento, envío y entrega reportada.

Registre cada supresión para que pueda explicarse y revisarse

Una supresión que no puede explicarse se convierte en un riesgo operativo. El registro debe permitir reconstruir qué solicitud se recibió, contra qué mensaje o intención se comparó, qué regla tomó la decisión y cuándo vencerá la ventana que impide una nueva creación.

Guarde la clave idempotente y de deduplicación, los identificadores de correlación internos y externos, el propósito, el destino normalizado, el estado previo y nuevo, la regla aplicada, la marca temporal, el vencimiento de la ventana y la referencia al mensaje existente. Cuando intervenga una excepción o revisión manual, registre el responsable, la justificación y el resultado.

Los datos de auditoría deben seguir políticas de acceso, minimización y retención adecuadas. Evite registrar secretos de autenticación en texto claro. Para OTP, es especialmente importante que la trazabilidad permita relacionar el evento sin exponer el secreto fuera de banda.

• Motivo de permitir, suprimir, revisar o reemplazar.
• Clave y correlación de la solicitud y del mensaje existente.
• Estado de ciclo de vida conocido y fuente del estado.
• Regla, versión de política y vencimiento aplicados.
• Responsable y justificación para excepciones manuales.
• Datos mínimos necesarios para diagnóstico y auditoría.

Defina excepciones sin convertirlas en una vía de evasión

Las excepciones deben estar predefinidas, ser verificables y dejar trazabilidad. Un cambio material de contenido, un nuevo evento de negocio, un cambio de canal autorizado, un incidente operativo o una solicitud verificable de reenvío pueden justificar que una solicitud no se trate como duplicado.

En autenticación, generar un nuevo secreto y reenviar un secreto existente son decisiones distintas. El secreto aceptado debe poder utilizarse una sola vez mientras sea válido. Además, generar un nuevo secreto no debe reiniciar el control de intentos fallidos cuando este sea aplicable. La deduplicación no debe debilitar controles de seguridad ni sustituir la limitación de intentos.

No use excepciones para superar límites de frecuencia, ocultar fallos de integración o repetir mensajes comerciales sin una base de consentimiento y una política aplicable. La deduplicación técnica debe convivir con las reglas de consentimiento, exclusión, frecuencia y contenido, pero no reemplazarlas.

• Cambio material verificable de contenido o estado.
• Nuevo propósito o nuevo evento de negocio.
• Cambio de canal autorizado y trazable.
• Reenvío solicitado y verificable por el usuario.
• Incidente con procedimiento de aprobación y registro.
• Nunca reiniciar controles de intentos solo por crear un nuevo OTP.