Eventos duplicados y fuera de orden en A2P SMS: cómo reconciliarlos sin perder evidencias

Por qué los eventos pueden duplicarse, retrasarse o llegar fuera de orden

En una integración A2P, un envío puede producir observaciones en más de una etapa: la solicitud a una API, una respuesta de aceptación o rechazo, una interacción SMPP y, si está disponible, un informe de entrega (DLR). Esas señales no necesariamente llegan juntas ni en el orden en que ocurrieron los hechos. También puede haber reintentos de notificación o eventos repetidos.

La semántica concreta depende de la interfaz y del proveedor. No hay una precedencia universal que permita concluir, para todos los sistemas, que un evento API prevalece sobre uno SMPP o que cualquier DLR significa lo mismo. Documenta qué representa cada evento en tu integración antes de usarlo para actualizar un estado.

• Separa el momento en que el sistema afirma que ocurrió un evento del momento en que tu plataforma lo recibió.
• Trata los mensajes repetidos como una posibilidad operativa, no como prueba de que el hecho subyacente ocurrió varias veces.
• No asumas que un evento ausente equivale a fallo, entrega o cancelación.

Separa el registro original de la vista de estado calculada

Mantén dos conceptos distintos. El registro de eventos conserva lo recibido; la proyección operativa resume lo que la plataforma puede afirmar en este momento. Si una regla de reconciliación cambia, la proyección puede recalcularse a partir del registro, sin borrar ni reescribir las evidencias que originaron el resultado.

Para cada evento conserva, cuando estén disponibles, el contenido recibido, la fuente o interfaz, el identificador de correlación, los tiempos declarados y observados, y el resultado de validaciones. Evita reemplazar un evento anterior por otro posterior solo porque este último parezca más concluyente.

La retención, protección contra alteraciones y requisitos de auditoría deben ajustarse a las obligaciones de tu organización y a los contratos aplicables. No existe aquí una garantía universal de almacenamiento inmutable.

• Guarda la observación original y registra por separado cualquier normalización.
• Versiona las reglas con las que calculas la proyección.
• Permite reconstruir qué eventos y reglas produjeron el estado mostrado.

Define identidad y deduplicación sin asumir una clave global

No des por sentado que existe un identificador único compartido entre API, SMPP, agregadores y operadores. Un identificador puede ser válido solo dentro de una cuenta, conexión, proveedor o periodo. Define el ámbito de cada identificador según la documentación de la interfaz concreta.

Si no hay una clave fiable, no unas eventos solo porque coincidan el destinatario, el texto y una hora aproximada: dos mensajes legítimos pueden compartir esos atributos. En ese caso, conserva ambos y márcalos como posibles duplicados o como correlación incierta, en lugar de descartar evidencia.

La normalización del número puede facilitar búsquedas, pero no demuestra por sí sola que dos registros correspondan al mismo envío. E.164 es una recomendación de numeración; no aporta por sí misma una regla de correlación de mensajes.

• Usa primero el identificador documentado por la interfaz y su ámbito: cuenta, conexión o proveedor.
• Registra las reglas de deduplicación y el motivo de cada coincidencia.
• Si la correlación es ambigua, conserva el evento y evita fusionar mensajes automáticamente.

Ordena con cautela: tiempo declarado, tiempo observado y secuencia

Conserva por separado la marca temporal incluida por el emisor del evento y la hora en que tu sistema lo observó. Una hora declarada puede describir el momento de origen; la hora observada documenta cuándo llegó a tu plataforma. Ninguna debe sustituir silenciosamente a la otra.

Si la interfaz proporciona una secuencia o versión con semántica documentada, evalúa usarla dentro del ámbito para el que es válida. Si no existe una señal de orden fiable, no conviertas el orden de llegada en una cronología definitiva. Una regla estable de desempate puede hacer repetible el cálculo, pero no prueba qué ocurrió primero.

Registra zona horaria, precisión y posibles problemas de reloj cuando esos datos estén disponibles. Si faltan, conserva esa limitación en la evaluación del evento.

• Guarda al menos tiempo declarado y tiempo de recepción como campos distintos.
• Aplica secuencias solo si conoces su alcance y significado.
• Marca como incierto el orden relativo cuando la evidencia no lo resuelve.

Define transiciones explícitas y no infieras entregas

Diseña una máquina de estados para tu sistema a partir de los significados documentados por cada interfaz. No existe una precedencia universal entre aceptación, error, estado intermedio y DLR que pueda aplicarse sin conocer el proveedor y el contrato técnico.

Una aceptación de envío indica únicamente lo que la interfaz documenta sobre la solicitud. Un DLR debe interpretarse según su origen y semántica; su recepción no equivale automáticamente a una verificación independiente de que la persona vio el SMS o de que el mensaje llegó al dispositivo en todos los casos.

Cuando la evidencia no alcance para decidir, muestra un estado como «pendiente», «desconocido» o «en conflicto» según tu modelo. El nombre debe dejar claro que no es una entrega confirmada.

• Documenta qué eventos permiten cada transición y qué significan en esa integración.
• Define condiciones para conservar un estado incierto y para elevar una contradicción.
• No conviertas ausencia de DLR, aceptación o un código no interpretado en entrega confirmada.

Trata contradicciones y DLR tardíos sin perder el historial

Si llega un DLR después de que la interfaz haya informado un fallo, o si dos fuentes parecen contradecirse, conserva ambos eventos y evalúa su significado conforme a la documentación aplicable. No elimines el evento antiguo ni elijas automáticamente el más reciente: la hora de recepción no establece por sí sola cuál tiene mayor autoridad.

La proyección puede actualizarse cuando una nueva observación aporta evidencia relevante, pero debe quedar constancia de qué cambió, cuándo se recalculó y con qué regla. Si el conflicto no puede resolverse, es más preciso mantenerlo visible que ocultarlo tras un único estado definitivo.

• Registra contradicciones como una condición explícita, no como una sobrescritura silenciosa.
• Define cuándo una regla permite resolver un conflicto y cuándo requiere revisión.
• Conserva los eventos tardíos para auditoría y reprocesamiento.

Haz que la reconciliación sea repetible y auditable

Un reprocesamiento debería producir el mismo resultado si se ejecuta con el mismo conjunto de eventos, las mismas reglas y la misma versión de configuración. Para acercarte a esa propiedad, separa la ingestión de la proyección y evita que el resultado dependa de efectos secundarios no registrados.

La idempotencia puede aplicarse al procesamiento de una notificación cuando existe una identidad fiable y un ámbito definido. Si no los hay, deduplicar agresivamente puede descartar evidencia válida. Es preferible registrar el criterio usado, conservar la observación recibida y señalar las coincidencias inciertas.

Supervisa patrones anómalos, como aumentos de eventos repetidos, demora inusual entre tipos de evento o contradicciones recurrentes. Las alertas deben describir lo observado; no atribuyas una causa sin evidencia.

• Versiona las reglas de proyección y registra la versión aplicada.
• Permite recalcular estados a partir del historial conservado.
• Mide duplicados, retrasos y conflictos por interfaz y ámbito, sin convertirlos en garantías de calidad.

Ejemplo: aceptación, fallo temporal y DLR tardío

Supón que la API responde con una aceptación de la solicitud. Más tarde llega una señal que tu integración interpreta como fallo temporal y, después, aparece un DLR. Los nombres y significados exactos deben provenir de la documentación de ese proveedor; este ejemplo no establece una secuencia normativa.

Primero conserva los tres eventos con sus tiempos declarados y de recepción, sus identificadores y el ámbito conocido. Comprueba si pueden correlacionarse con seguridad. Después aplica las reglas documentadas: la aceptación no demuestra entrega, el fallo temporal no debe borrarse por la llegada posterior de otro evento y el DLR solo puede elevar la conclusión hasta lo que su semántica permita.

Si la documentación establece que ese DLR representa un resultado de entrega para el mensaje correlacionado, la proyección puede reflejar ese resultado con su alcance claramente indicado. Si su semántica, identidad o relación con el envío no están confirmadas, conserva el estado como incierto o en conflicto. En ningún caso el ejemplo permite afirmar que el usuario vio el SMS o que hubo recepción independiente en el móvil.

• Concluir: existen una aceptación, una señal de fallo y un DLR recibidos; su correlación y significado deben verificarse.
• No concluir sin documentación: que la aceptación confirma entrega o que el DLR prueba recepción efectiva por el usuario.
• Dejar pendiente: cualquier conflicto de identidad, orden o semántica que la evidencia disponible no resuelva.