Planteamiento y alcance
Esta pregunta de diseño de ingeniería de datos evalúa el ciclo de vida completo de un registro rechazado: detección, cuarentena, corrección, reproducción (replay) y cierre. La respuesta debe proteger el rendimiento (throughput) en la ruta correcta mientras se preserva suficiente evidencia para reproducir una decisión.
Qué evalúa el entrevistador
- Distinguir fallas de esquema, de reglas de negocio, de duplicados, de retraso (late data) y de "píldoras venenosas" (poison pills).
- Diseñar un registro de cuarentena con evidencia de la carga útil (payload), posición de origen y motivo.
- Utilizar idempotencia, reglas versionadas y un estado auditable para la reproducción.
- Cubrir contrapresión (backpressure), alertas, privacidad, retención y propiedad (ownership).
Preguntas aclaratorias para hacer
Aclare si la entrada es batch, streaming o ambas; si los registros válidos pueden confirmarse (commit) de forma independiente; si los eventos tienen un event_id estable, marca de tiempo del negocio y offset de origen; si la reproducción lee el evento original o vuelve a consultar la fuente; y qué requisitos de privacidad y retención aplican.
La respuesta de 30 segundos
Separaría una capa cruda (raw) inmutable, un enrutador de validación, una ruta de datos válidos y una ruta de cuarentena. Cada registro fallido conserva su evidencia, posición de origen, versión de la regla, motivo y estado; los registros válidos se escriben de manera idempotente por event_id. Después de una corrección, un lote de reproducción ejecuta la misma transformación y límite de escritura, con una versión de regla controlada y métricas de conciliación que demuestran que los registros no se perdieron silenciosamente ni se duplicaron.
Análisis detallado paso a paso
1. Preservar los hechos antes del enrutamiento
Escriba primero el evento entrante en un almacenamiento inmutable o en un registro reproducible, incluyendo la fuente, partición/offset, hora de recepción, event_id y un hash del payload. Una falla de análisis sintáctico (parse) o de esquema debe enrutarse con un código de error a la cuarentena en lugar de descartarse. Los registros aprobados continúan por la ruta normal, de modo que un registro defectuoso no detenga un lote o partición no relacionados.
2. Hacer que la cuarentena sea accionable
Almacene el payload o una referencia controlada, los campos fallidos, el nombre y versión de la regla, la hora del primer fallo, la posición de origen, el recuento de reintentos, el lote de corrección y estados como open, ready_for_replay, replayed o rejected. Cifre o minimice los campos confidenciales y aplique una política de retención. Una tabla de cuarentena es una cola operativa, no un archivo ilimitado.
3. Dar a la reproducción el mismo límite de corrección
Versione la regla de corrección y nunca sobrescriba el evento original. Un trabajo de reproducción selecciona un estado y una versión de regla aprobados, valida una muestra pequeña o un destino sombra (shadow target), y luego llama a la misma ruta de transformación y escritura utilizada por el tráfico en vivo. Utilice event_id más la versión del negocio como clave de idempotencia; defina si un conflicto es un upsert, un no-op o una nueva versión. Reproducir dos veces debe converger en el mismo resultado.
4. Manejar duplicados, retrasos y poison pills
Detecte duplicados con event_id, posición de origen o una ventana de deduplicación documentada; un offset por sí solo no es una identidad de negocio. Enrute los eventos tardíos según la hora del negocio y especifique cómo los watermarks o los backfills afectan los resultados aguas abajo (downstream). Limite los reintentos para las poison pills y asígnelas a un responsable o a un estado de rechazo terminal, evitando que un solo registro consuma toda la capacidad de los workers.
5. Demostrar la salud del sistema con observabilidad
Rastree la tasa de aprobación de datos válidos, el recuento de cuarentena por fuente y regla, la antigüedad del registro sin resolver más antiguo, la tasa de éxito de la reproducción, los conflictos de escritura duplicada, la latencia de extremo a extremo y la frescura. Genere alertas sobre umbrales o aísle una fuente antes de detener todo el pipeline. Concilie los recuentos de registros crudos, válidos, en cuarentena, reproducidos y rechazados para cada lote o rango de offsets; las diferencias no explicadas son incidentes.
Un ejemplo sólido de respuesta
Primero aclararía la identidad del evento y los requisitos de consistencia. Luego persistiría el evento crudo de forma inmutable, validaría el esquema, las reglas de negocio, los duplicados y el orden, y enrutaría las fallas a un almacén de cuarentena en lugar de descartarlas. El registro de cuarentena mantiene una referencia al payload, el offset de origen, la versión de la regla, el motivo detallado y el estado del ciclo de vida. Los registros válidos y los registros reproducidos comparten la misma ruta de escritura idempotente identificada por event_id y versión del negocio. Las correcciones crean un lote de reproducción aprobado sin mutar el evento original; probaría una muestra pequeña, limitaría los reintentos de poison pills y haría explícito el comportamiento de los eventos tardíos. Finalmente, monitorearía la antigüedad en cuarentena, el éxito de la reproducción, los conflictos de escritura, la frescura y la conciliación de recuentos, protegiendo al mismo tiempo los campos confidenciales y aplicando la retención.
Errores comunes
- Descartar filas fallidas o registrar únicamente una cadena de texto de error.
- Omitir la posición de origen, la identidad del evento o la versión de la regla.
- Implementar la reproducción con una transformación separada que pueda divergir del tráfico en vivo.
- Reintentar poison pills sin un límite o responsable asignado.
- Tratar la cuarentena como un basurero sin estados, retención ni condición de cierre.
- Observar únicamente una tasa de éxito agregada en lugar de desglosar por dimensiones de fuente, regla y antigüedad.
Preguntas de seguimiento y respuestas
¿Cómo se protegen los datos personales en cuarentena?
Conserve únicamente los campos mínimos necesarios para el diagnóstico, cifre los payloads confidenciales, restrinja el acceso y recupere el original a través de una referencia controlada. Audite las lecturas y aplique la eliminación al alcanzar el plazo de retención.
¿Qué sucede si llegan nuevos datos durante la reproducción?
Utilice un lote de reproducción separado y versiones de eventos explícitas. Combine mediante la clave de idempotencia; si el orden importa, defina un límite de partición o entidad y registre las decisiones ante conflictos.
¿Cuándo detendría todo el pipeline?
Únicamente ante un cambio disruptivo de esquema (breaking schema), un destino no disponible o un riesgo de corrupción que pueda contaminar los datos válidos. Normalmente, una sola fuente o regla defectuosa debe aislarse mientras las demás rutas continúan.
¿Cómo demuestra que no hubo pérdidas?
Cree un registro contable (ledger) para cada lote de entrada o rango de offsets y concilie los recuentos de registros crudos, válidos, en cuarentena, reproducidos y rechazados. Tome muestras de conjuntos de event_id e incluya la antigüedad de registros no resueltos en el SLO de calidad.