Pipeline incremental de identidad / transacciones

Problema

La identidad y las transacciones no llegan en el orden en que el negocio cree que ocurrieron. Un registro que debería pegarse al lunes aparece el miércoles. Un job incremental ingenuo o se lo pierde o reprocesa tanta historia que la factura del warehouse se vuelve el incidente.

El sistema tenía que emparejar entidades en el tiempo, aplicar hechos nuevos sin reconstruir la tabla entera, y producir una clave que los procesos de abajo pudieran joinear.

Restricciones

• Cliente no publicado. Solo arquitectura.
• Hora de llegada ≠ hora de negocio. El timestamp de ingesta no es el grain.
• El matching es temporal. “El mismo id hoy” no es “la misma entidad a la fecha del evento.”
• El control de costo es un requisito, no una optimización posterior. Un full scan disfrazado de incremental falla esta restricción.

Arquitectura

Los extracts de fuente conservan el payload. Un paso de match asigna la clave durable con ventanas de validez o lógica as-of. Los modelos incrementales solo leen lo que el predicado dice que es nuevo o tardío. El serving consume el grain ya emparejado — no el dump de staging.

Decisiones y trade-offs

• No se incrementaliza una clave borrosa. Si dos personas dibujarían primary keys distintas, no hay pipeline incremental. Hay un full load frecuente con pasos extra. (La misma disciplina que Understand the grain.)
• Lo tardío es un camino de primera clase. Una ventana de lookback, un merge por tiempo de negocio o un modelo aparte de catch-up gana a “reprocesamos 90 días cada noche.”
• La cadencia sigue a la decisión. Un matching que alimenta una lista operativa de la mañana no necesita el mismo schedule que una tabla de eventos para debug. (How I choose cadence.)
• El costo aparece en el predicado. Si no puedes nombrar updated_at, una partición o un cursor CDC, no puedes afirmar incrementalidad.

Implementación

Modelado, incrementalidad y confiabilidad en el camino match → incremental → serve. El tooling se queda en lo que puedo publicar: procesamiento incremental, matching temporal, control de costo. Cloud y sistemas del cliente no se nombran aquí.

Resultado

Un camino donde los hechos tardíos pueden aterrizar sin convertir cada corrida en un rebuild histórico, y donde la clave servida es lo bastante estable para joinear. No se publican SLAs de cliente ni ahorros en dólares.

Qué aprendí

Lo caro casi nunca es lo ingenioso del matcher. Es reconstruir porque el grain y el predicado incremental nunca fueron la misma frase. Primero el claim, luego la ventana, luego el schedule.