Si tu API no maneja explícitamente datos que llegan 24 horas tarde, no estás construyendo para producción. Estás construyendo para una simulación.
El 5-15% de tus eventos ya están llegando fuera de orden. Lo saben en Uber, en LinkedIn, en Confluent. Y a ti te da igual porque mides en processing time, no en event time.
*El problema no es que los datos lleguen tarde. Es que tu API los trata como si nunca fuera a pasar. *
La mayoría de los desarrolladores piensa que "late data" es un problema de stream processing. De Kafka Streams, de Apache Beam, de cosas que solo pasan cuando tienes millones de eventos por segundo.
Y están equivocados.
Un webhook de confirmación de pago que llega 10 minutos tarde puede duplicar cargos. Un evento de stock que aparece 30 segundos después del cierre de inventario puede descuadrar balances. Un sensor IoT que reporta temperatura 2 horas tarde puede activar una alarma falsa de incendio.
*Los datos tardíos no son un edge case. Son el caso real. *
---
El Error de Fábrica: Tratar los Datos Tardíos como Excepción
La sabiduría convencional dice:
❌ Los eventos llegan en orden. Si alguno llega tarde, lo ignoramos o lo metemos en la ventana actual.
❌ Processing time (la hora del reloj del servidor) es suficiente para ordenar eventos.
❌ Manejar lateness es overengineering. Para eso están los timeouts.
La evidencia dice lo contrario:
✅ En clusters de Kafka en producción (Uber, LinkedIn), el 5-15% de los eventos llegan más de 1 segundo tarde. No minutos. Segundos.
✅ Apache Kafka Streams tiene una gracia por defecto de 24 horas para ventanas de sesión. Veinticuatro. Horas. Porque saben que los datos tardíos son la norma.
✅ Google Cloud Dataflow introdujo 'allowed lateness' como un parámetro de primera clase — no como un parche, como parte fundamental del pipeline.
*La API promedio está diseñada para el happy path. Y en producción, el happy path no existe. *
---
La Evidencia: 5-15% de Eventos Tardíos en Producción
No me lo invento. Los datos vienen de ingenieros que gestionan clusters de Kafka con millones de eventos por segundo:
- Uber: Documentaron públicamente que los eventos de trazabilidad de viajes llegan fuera de orden de forma constante. Su solución no fue "hacer que los eventos lleguen a tiempo". Fue rediseñar su pipeline para asumir desorden como estado base.
- LinkedIn: En su infraestructura de Kafka, encontraron que el 5-15% de los eventos superan el umbral de 1 segundo de retraso. Esto incluía eventos de actividad de usuarios, mensajería y métricas de sistema.
- Confluent: La documentación de Kafka Streams establece 24 horas de grace period por defecto en ventanas de sesión. No porque sea bonito. Porque han visto sistemas en producción donde eventos que deberían haber llegado en la misma sesión aparecen horas después.
*El patrón es consistente: los datos siempre llegan tarde. La pregunta no es si va a pasar. Es si tu API está preparada. *
El Ejemplo Clásico: El Webhook de Pago
Tu sistema de pagos recibe un webhook de confirmación. El usuario ha pagado. Genial.
Pero 10 minutos después llega otro webhook del mismo pago. Retry del gateway. O un reintento de la pasarela. O un retardo en la cola.
Si tu API trata eso como un evento nuevo:
- Duplicas el cobro
- Marcas fraude positivo falso
- Descuadras el stock
- El usuario recibe dos emails de confirmación
*Todo porque no diseñaste para late data. *
---
De Processing Time a Event Time: El Cambio que Duele
La mayoría de los desarrolladores usa processing time porque es simple.
El problema: no es determinista. El mismo evento procesado dos veces puede terminar en ventanas diferentes dependiendo de la carga de la red, los retries, o el clock skew entre servidores.
La alternativa: event time.
Esto hace tu API determinista. Pero introduce el problema de lateness: ¿qué haces cuando un evento con timestamp de hace 3 horas aparece ahora?
*Estás intercambiando simplicidad por corrección. Y la mayoría no lo hace. *
---
El Framework de 5 Capas para Datos Tardíos (Late Data Pipeline)
Aquí está el método. Lo he aplicado en pipelines de producción y funciona.
1. Clasifica tus fuentes por perfil de latencia
No todos los datos llegan tarde igual. Necesitas medir.
Mide P50, P95 y P99 de retraso en producción. No en staging. No en desarrollo. En producción.
Si tu P99 es 5 segundos, configura tu grace period en 10 segundos. Si tu P99 es 3 horas, necesitas un diseño completamente diferente.
*No adivines. Mide. *
2. Elige una estrategia de watermark
El watermark es el punto de corte: "a partir de aquí, asumo que no van a llegar más eventos con timestamp anterior a esto".
Dos estrategias principales:
Watermark periódico: Avanza el watermark cada N segundos. Simple, pero puedes descartar datos legítimos si el retraso supera el periodo.
Watermark por puntuación: Avanzas el watermark cuando recibes un evento con timestamp más reciente. Más preciso, pero puedes quedarte esperando para siempre si un productor se cae.
3. Diseña canales de side output explícitos
Aquí es donde la mayoría falla. Reciben un evento tardío y:
❌ Lo ignoran (bug silencioso)
❌ Lo meten en la ventana actual (agregación incorrecta)
❌ Lo procesan sin marcar (no sabrás que pasó)
La solución:
Los eventos tardíos van a un pipeline de reconciliación. Se loguean. Se revisan. No desaparecen.
*Un evento tardío ignorado es un bug que explotará a las 3 de la mañana. *
4. Construye consumidores idempotentes
Cuando trabajas con late data, los eventos pueden llegar duplicados o fuera de orden. Tu consumidor debe poder manejar eso sin corromper estado.
Patrones que funcionan:
- Upsert: inserta o actualiza, no asume que es nuevo
- Version vectors: cada evento lleva un número de versión
- Deduplication keys: IDs únicos de evento para detectar duplicados
5. Prueba con datos tardíos simulados
Esto es lo que nadie hace. Y es lo más importante.
Inyecta delays artificiales en tu CI/CD. Haz que el 10-20% de los eventos de prueba lleguen tarde.
*Si pruebas solo el happy path, tu API está rota y no lo sabes. *
---
El Patrón de Retraction Stream: Lo Más Robusto, Lo Menos Usado
El approach más sofisticado para late data es el retraction stream.
En lugar de ignorar el evento tardío o meterlo en la ventana actual, emites un evento de corrección:
- Cuando el evento tardío llega, emites un retraction del resultado anterior.
- Recalculas con el dato correcto.
- Emites un nuevo resultado con el valor corregido.
Este patrón es el más robusto pero también el más complejo. Requiere que tus consumidores sepan manejar retractions. Pero si tienes dashboards financieros, balances de inventario, o cualquier sistema donde los totales deban cuadrar, *no hay alternativa. *
---
Las 3 Excusas Más Comunes (y Por Qué No se Sostienen)
"Mi sistema no tiene datos tardíos — los eventos llegan en orden"
Estás midiendo en processing time. No en event time.
Conecta un monitor que mida la diferencia entre el timestamp del evento y la hora de llegada. Te vas a llevar una sorpresa.
Network jitter, retries, clock skew entre servidores, backpressure en colas. Todo introduce desorden. *Si tus eventos llegan 100% en orden, probablemente tienes un sistema síncrono de un solo hilo que no escala. *
"Manejar late data es overengineering"
Depende del impacto de negocio.
Si un webhook de pago tardío duplica un cobro, el coste de NO manejar late data es enorme. Si una lectura de sensor tardía desencadena una orden de reposición incorrecta, tienes stock fantasma.
*Un simple side output + log de reconciliación cuesta casi nada. El coste de no tenerlo puede ser catastrófico. *
"Mi framework lo maneja automáticamente"
No. Los frameworks te dan herramientas (allowed lateness, grace periods, watermarks). Pero tú tienes que configurarlas explícitamente.
Kafka Streams por defecto te da 24 horas de grace period. Pero si no configuras suppress y side outputs, los eventos tardíos se mezclan en tus agregaciones y generas métricas incorrectas.
*El framework no va a tomar la decisión de negocio por ti. Tú decides qué significa "tarde" para tu dominio. *
---
Resumen: Lo Que Te Llevas
- Mide la latencia real: P50, P95, P99 de tus eventos en producción antes de diseñar nada.
- Elige watermark según tus SLAs: Periódico para simplicidad, por puntuación para precisión.
- Side outputs siempre: Los eventos tardíos no se ignoran ni se mezclan. Se loguean, se reconcilian.
- Idempotencia: Tus consumidores deben poder recibir el mismo evento dos veces sin corromper estado.
- Prueba con late data: Inyecta delays en CI/CD. Si no rompes tu API en tests, lo hará en producción.
*Los datos tardíos no son el problema. El problema es que sigues diseñando APIs como si no existieran. *
La próxima vez que despliegues un endpoint que recibe eventos asíncronos, pregúntate: ¿qué pasa si esto llega 24 horas tarde? Si no tienes respuesta, tu API no está lista para producción.
El mundo real no espera. Tus eventos tampoco.
Artículos relacionados
- Arquitectura de Edge Functions en Supabase: El Patrón de 5 Fases que Transforma Pipelines de Minutos a Segundos
- Late API: Why Most Developers Build APIs Backwards
- Late API: Programa tu Contenido en Redes Sociales con Código Real
- Sanity Webhooks y Content Pipelines: La Arquitectura que Nadie Te Explica
- Late API: El Patrón que Resuelve la Publicación Multi-Formato en LinkedIn y Twitter
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
