Avisos de infracciones que llegan desordenados: por qué pasa

Una integración recibe a las 10:03 el aviso de que un acta pasó a estado pagado y a las 10:07 el que informa su alta. Ninguna de las dos entregas se perdió, ambas devolvieron respuesta exitosa y el productor las emitió en orden. Aun así, el consumidor que aplica “lo último que llegó” termina con una infracción recién creada donde ya había un pago registrado.

El desorden no es una falla excepcional del transporte: es un resultado previsible de cómo se emiten, encolan y procesan las notificaciones. Antes de escribir la regla que reconstruye el estado conviene saber qué lo produce, porque cada causa deja una huella distinta y se corrige en un lugar distinto.

Llamamos desorden de entrega a la diferencia entre la secuencia en que ocurrieron los cambios y la secuencia en que el consumidor los recibe. No es lo mismo que perder un evento ni que recibirlo dos veces, aunque los tres problemas suelen aparecer juntos.

Ninguna capa del camino promete secuencia

RFC 9110 describe HTTP como un protocolo sin estado: la semántica de cada solicitud se entiende de manera aislada, y la relación entre las conexiones y los mensajes que viajan por ellas no altera cómo se los interpreta. Muchas implementaciones dependen de ese diseño para balancear carga entre servidores; es también lo que deja sin definir qué pasó primero entre dos avisos simultáneos sobre la misma patente.

Los formatos de evento tampoco lo agregan. CloudEvents exige que la combinación de source e id sea única para cada evento, lo que permite reconocer una reentrega, pero describir un evento no es ordenar la serie de estados de un acta. RFC 8417 es explícito para los tokens de eventos de seguridad: no define ningún mecanismo para ordenarlos en secuencia, y recomienda cautela al usar la hora de emisión con ese fin, porque todo sistema distribuido arrastra algún desvío de reloj.

De dónde sale el desorden

Las causas habituales son pocas:

• emisión concurrente: el productor despacha dos avisos del mismo recurso en paralelo y el segundo termina antes;
• reintento: una entrega demora o falla y vuelve a la cola mientras la siguiente ya fue aceptada;
• particionado: cuando la cola conserva el orden sólo dentro de cada partición, repartir por carga en vez de por recurso separa dos cambios de la misma acta;
• concurrencia en el consumidor: varios workers toman el mismo lote y el que empezó primero puede terminar último;
• reproceso: una corrección masiva reemite eventos antiguos: horas viejas, llegada nueva;
• varias fuentes del mismo hecho: dos proveedores o dos portales informan la misma acta con cadencias distintas.

Las últimas dos no son fallas: ahí la secuencia viene rota desde el origen, a veces a propósito, como cuando una jurisdicción republica su padrón de actas y otra fuente ya había informado las mismas. Un backfill correcto se ve igual que un incidente si nadie lo anunció.

La hora del evento no resuelve la duda

Un campo de hora describe cuándo el productor cree que pasó algo: la fecha de la infracción, la de su carga en el portal o la del aviso. CloudEvents admite que, si el momento de la ocurrencia no puede determinarse, ese atributo lleve otra hora —por ejemplo la actual—, siempre que los productores de un mismo source sean consistentes. Un evento válido puede entonces traer una hora más cercana a la emisión que al hecho. Sumado al desvío de relojes que señala RFC 8417, ordenar por hora sólo es estable cuando las diferencias son grandes.

Tampoco conviene mezclar la fecha del hecho con la de observación y la de procesamiento: esa distinción está en los tres relojes.

Cómo se ubica el tramo responsable

Atribuir el desorden requiere correlación, no intuición. W3C Trace Context define cómo propagar contexto de traza entre servicios con los encabezados traceparent y tracestate. Si el productor lo emite y el consumidor lo conserva, emisión, saltos intermedios y procesamiento quedan en una misma traza.

Con esa evidencia, cada causa muestra su firma:

1. el mismo identificador de evento repetido: reintento;
2. inversión sistemática entre dos tipos de evento: concurrencia en el productor;
3. inversión que aparece sólo bajo carga: concurrencia en el consumidor;
4. ráfaga de horas viejas concentrada en pocos minutos: reproceso.

Ninguna firma es concluyente por sí sola, pero todas descartan tramos y evitan pedirle al proveedor de datos de infracciones una prolijidad que no explicaría el patrón.

Qué registrar antes del próximo incidente

Guardá, junto a cada entrega, la hora declarada por el productor, la de recepción y la diferencia entre ambas. Medí esa diferencia por percentiles y por tipo de evento: una cola que empieza a llenarse puede mover la distribución antes de que aparezca un error visible.

Contá además las inversiones detectadas por patente. Si ese contador marca cero durante semanas, antes de dar por perfecto el transporte conviene comprobar que la regla de orden se haya ejercido alguna vez: un evento fuera de secuencia que aparece cada tantos meses encuentra el código sin probar.

Ubicada la causa, la reconstrucción determinista —revisión comparable, idempotencia y reconciliación— se trata en webhooks fuera de orden. Lo que cambia con el diagnóstico es la decisión: sabiendo si el desorden viene del productor, del transporte o de un reproceso anunciado, la respuesta deja de ser adivinar si el acta está paga o no.

Preguntas frecuentes

¿Recibir eventos desordenados significa que el proveedor los emitió mal?

No necesariamente. La emisión puede haber sido correcta y la secuencia romperse en un reintento, en una cola particionada o en el propio consumidor. Atribuir la causa exige correlacionar la emisión con la recepción, no suponerla.

¿Ordenar por la hora del evento alcanza para saber cuál es más nuevo?

Es una aproximación frágil. RFC 8417 advierte que las marcas de tiempo por sí solas no garantizan el orden, porque todo sistema distribuido arrastra algún desvío de reloj; y un campo de hora puede describir la emisión y no el hecho. Sirve para auditar demoras, no para decidir qué estado gana.

¿Un backfill se distingue de un incidente?

Sólo si alguien lo anuncia o si queda registrado. Un reproceso masivo produce una ráfaga de eventos con horas viejas y llegada nueva: la misma firma que una cola que estuvo demorada. Conviene que el productor marque los eventos reemitidos.

Notas relacionadas