Una integración recibe primero una actualización de dirección y, después, un evento que indica que el cliente todavía tiene la dirección anterior. Si aplica ambos mensajes en el orden de llegada, el registro acaba desactualizado. El problema no es que el segundo evento sea falso: puede ser válido y haber ocurrido antes.
Gestionar eventos fuera de orden requiere separar cuándo ocurrió un cambio de cuándo se recibió, y decidir qué fuente de información permite establecer cuál debe prevalecer. No existe una regla universal basada en la fecha. La decisión depende del tipo de evento, de cómo se generan los datos y de qué sistema tiene autoridad sobre ellos.
Por qué llegan eventos fuera de orden
Una cola, un webhook o un proceso de integración pueden añadir demora entre la generación de un evento y su consumo. Las entregas pueden reintentarse, procesarse en paralelo o atravesar rutas con latencias distintas. Por eso, dos eventos de la misma entidad pueden llegar en orden diferente al de su creación. También pueden repetirse si un emisor vuelve a intentarlo tras no recibir confirmación.
El orden puede conservarse dentro de un flujo concreto y no entre flujos distintos. Por ejemplo, los cambios de una cuenta podrían repartirse entre particiones, mientras los cambios de sus pedidos se procesan de manera independiente. No conviene asumir que una cola o una API garantizan un orden global salvo que esa propiedad esté documentada y se cumpla en la ruta real.
El efecto depende del contenido:
- Un evento de estado completo describe cómo queda un registro en un momento dado. Un estado antiguo aplicado después puede reemplazar campos más recientes.
- Un evento delta describe un cambio, como añadir una etiqueta o incrementar un contador. Descartarlo por su antigüedad podría eliminar una modificación legítima que todavía no se había aplicado.
Antes de elegir una regla, identifica si los mensajes son estados completos, cambios parciales o una combinación. La estrategia correcta para una actualización de perfil puede no servir para una operación financiera o una transición de pedido.
Recepción, hora del evento y secuencia de negocio
La hora de recepción indica cuándo el sistema consumidor observó el mensaje. Sirve para medir demora y ordenar lo recibido en ese consumidor, pero no demuestra cuándo sucedió el cambio original.
La hora del evento pretende reflejar cuándo se produjo o registró el cambio. Puede ser útil como diagnóstico, aunque depende del reloj, de la precisión y de las convenciones del emisor. Dos sistemas pueden tener relojes desajustados, y un evento generado durante una reanudación puede llevar una hora que no representa con exactitud el orden de negocio. Una fecha más reciente no es, por sí sola, una prueba suficiente de precedencia.
La secuencia de negocio expresa el orden que importa para esa entidad: por ejemplo, la versión 12 de una ficha sucede a la 11, o una operación se confirma después de otra. Si el sistema de origen proporciona una versión monotónica o un número de secuencia fiable y asociado a la misma entidad, suele ser una señal más sólida que la hora. Comprueba su alcance: puede reiniciarse, ser local a un proceso o no comparar cambios de entidades diferentes.
Registra estos valores por separado. No reutilices un único campo llamado “fecha” para decidir precedencia, medir retrasos y conservar auditoría; cada propósito requiere una interpretación clara.
Cómo reconocer una actualización obsoleta sin perder cambios válidos
Una actualización es obsoleta solo respecto de una regla definida y del estado actual que conoce el consumidor. Por ejemplo, si conserva la versión 18 de un cliente y recibe un estado completo de la versión 16, puede rechazarlo como anterior. En cambio, no debería descartar automáticamente un delta válido solo porque su marca temporal sea menor: quizá añade un dato que no está presente en el evento posterior.
Para evaluar cada mensaje, comprueba:
- Identidad y alcance: a qué entidad, campo o agregado se refiere. Dos cambios pueden ser independientes y no requerir una elección entre ambos.
- Tipo y versión: si contiene un estado completo o un delta, y si su secuencia puede compararse con la ya aplicada.
- Precondiciones: si la transición es válida desde el estado actual. Un cambio a “enviado” no debería revertir sin explicación un pedido ya “entregado”.
- Autoridad: qué sistema puede decidir el valor de ese campo. Una actualización de perfil y una corrección proveniente del sistema maestro no tienen necesariamente el mismo peso.
La comparación y la escritura deben ser coherentes. Si dos consumidores leen la versión 16 y ambos intentan guardar cambios, una comprobación hecha antes de escribir puede quedar obsoleta. Usa una actualización condicionada por la versión observada o una operación equivalente en el almacenamiento. Así, el consumidor puede detectar que el registro cambió antes de confirmar el suyo.
Criterios para resolver conflictos
Prioriza la señal más fiable que realmente exista; no construyas una jerarquía ficticia a partir de campos que no garantizan el orden. Estos criterios pueden combinarse, siempre que su significado esté documentado:
- Versión o secuencia por entidad: acepta el estado completo si avanza la versión; ignora una versión ya aplicada o anterior. Define qué hacer con saltos, reinicios y versiones ausentes.
- Estado y transición permitida: valida el cambio frente a una máquina de estados o reglas de negocio. Una transición inválida debe generar una revisión, no convertirse silenciosamente en una actualización.
- Autoridad por campo: asigna la propiedad de cada dato a un sistema responsable. Si dos fuentes editan legítimamente el mismo campo, establece una política explícita, como revisión o prioridad acordada, no una regla improvisada de “último mensaje recibido”.
- Comparación de contenido: aplica deltas idempotentes cuando sea posible y evita sustituir un registro entero por un mensaje parcial. Si el evento no permite saber qué cambió, consulta la fuente de verdad antes de sobrescribir.
“Última escritura gana” puede ser aceptable para campos de baja criticidad si los relojes y la política están suficientemente controlados. No es una regla neutral: puede borrar cambios válidos y ocultar conflictos. Para decisiones sensibles, conviene conservar ambas versiones o bloquear la resolución automática.
Qué hacer si no hay una secuencia fiable
Cuando el emisor no ofrece versión comparable, no intentes inferir un orden exacto a partir de la hora de recepción. Elige una respuesta acorde con el impacto de equivocarse:
- Consultar el estado actual al sistema de origen antes de actualizar, si existe una API de lectura fiable. Esto reduce la dependencia de un mensaje atrasado, aunque hay que contemplar que la lectura y la escritura también pueden competir con cambios posteriores.
- Aplicar solo campos independientes si el evento identifica con claridad qué modificó. Conserva los demás valores y evita reemplazos completos.
- Retener el conflicto para reconciliación cuando falte contexto o el dato sea importante. Guarda el mensaje, la entidad y la causa de la decisión para que pueda revisarse.
- Definir una prioridad de origen cuando el negocio haya determinado qué sistema manda sobre un dato. Comunica esta regla a los equipos y revisa sus excepciones.
Una cola de revisión o una consulta posterior no deben convertirse en un limbo invisible. Establece quién atiende los casos, cómo se reintentan y qué señal indica que se han resuelto. Si no es posible decidir automáticamente, mostrar incertidumbre es más seguro que presentar como actual un dato dudoso.
Pruebas y registros que permiten verificar el comportamiento
Prueba el contrato de integración, no solo el recorrido ideal. Para una misma entidad, envía dos cambios en orden inverso; repite un evento ya procesado; retrasa uno durante un reintento; y provoca que dos actualizaciones se escriban casi a la vez. Incluye versiones iguales, ausentes o inesperadas si esos casos son posibles en el origen.
Comprueba no solo el valor final, sino también la decisión: aceptado, ignorado como duplicado u obsoleto, fusionado, retenido o rechazado por transición inválida. Verifica que los mensajes repetidos no produzcan efectos adicionales y que los eventos válidos no se pierdan por una regla basada únicamente en fechas.
Registra el identificador del evento, la entidad, la fuente, la versión o secuencia disponible, la hora de evento y la de recepción, la versión previa y posterior, y el motivo de la decisión. Evita incluir datos personales innecesarios en los registros. Observa la antigüedad de los mensajes y el volumen de conflictos: un aumento puede señalar retrasos, reintentos o un cambio del emisor, no necesariamente un fallo del consumidor.
Lista de decisiones antes de poner en marcha la integración
- ¿Cada mensaje representa un estado completo, un delta o ambos tipos?
- ¿Qué campo establece precedencia y quién garantiza su alcance y continuidad?
- ¿Qué sistema es autoridad para cada dato, y qué cambios puede aceptar cada fuente?
- ¿Cómo se evitan duplicados y escrituras concurrentes que invalidan una comprobación?
- ¿Qué ocurre ante secuencias faltantes, transiciones inválidas y conflictos ambiguos?
- ¿Quién revisa los casos retenidos y cómo se mide el retraso hasta su resolución?
La decisión práctica consiste en usar la señal de orden más fiable disponible, limitar cada evento a los datos que realmente modifica y hacer explícita la incertidumbre. Así, un mensaje retrasado puede reconocerse sin descartar a ciegas cambios legítimos ni permitir que una actualización antigua sobrescriba el estado vigente.