Planteamiento y contexto
Esta pregunta evalúa si un ingeniero de datos puede transformar una sola solicitud de eliminación en un ciclo de vida auditable, reintentable y a través de múltiples sistemas. La eliminación es más que un DELETE en la base de datos principal; abarca tablas derivadas, cachés, índices, registros de eventos, respaldos y procesadores. Cubre el descubrimiento, el mapeo de identidades, las retenciones legales, la idempotencia, la recuperación y la prueba de finalización.
Qué evalúa el entrevistador
Las respuestas sólidas definen el alcance y las excepciones, para luego construir un catálogo de datos con propietarios. Un flujo de trabajo envía comandos de eliminación o anonimización a lo largo de las dependencias y espera confirmaciones de recepción. Los estados distinguen entre solicitado, en ejecución, verificado y bloqueado, con un registro de auditoría inmutable. Si los respaldos físicos no pueden modificarse de inmediato, explica el borrado criptográfico, la expiración, el aislamiento de la restauración y la reaplicación.
Preguntas para clarificar
- ¿Qué identifica a la persona y cómo se vinculan el correo electrónico, el dispositivo, el pedido y los identificadores anónimos?
- ¿Qué registros deben desaparecer y qué facturas, evidencia de fraude o retenciones legales deben permanecer temporalmente?
- ¿Se incluyen los índices de búsqueda, cachés, agregados, registros de eventos, almacenamiento de objetos, respaldos y procesadores SaaS?
- ¿El objetivo es la eliminación física, la anonimización irreversible o el cese de uso dentro de un plazo límite?
- ¿Qué define la finalización, el tiempo de espera (timeout), la revisión humana y el comprobante del usuario?
Estructura de respuesta de 30 segundos
“Catalogaría los sistemas, campos, propietarios, reglas de retención y capacidades de eliminación. Cada solicitud crea un caso de eliminación inmutable y tareas idempotentes. El orquestador envía comandos de eliminación, anonimización o borrado de claves a lo largo de las dependencias; cada consumidor devuelve el alcance, la versión y un resumen de verificación. Las fallas se reintentan o escalan. Los datos con retención legal se congelan a nivel de acceso con una excepción registrada y se eliminan cuando la retención expira. La finalización requiere cobertura del catálogo, confirmaciones de recepción, lecturas por muestreo y un registro de auditoría; el usuario recibe un estado verídico sin exponer la topología interna.”
Respuesta detallada paso a paso
Paso 1: Construir un mapa de datos e identidad
Cataloga tablas, buckets, índices, clases de campos, propietarios, dependencias downstream, ciclos de respaldo y procesadores. Mapea el ID de usuario estable a pedidos, dispositivos, correos electrónicos y tokens anónimos. Sin uniones de identidad confiables, la afirmación de una eliminación completa no resulta creíble.
Paso 2: Definir la política de eliminación
Clasifica los registros como eliminación directa, anonimización, retención agregada o retención legal. Los registros financieros o la evidencia de fraude pueden requerir retención, pero minimiza los campos, restringe el acceso y registra la base legal. Aplica versiones a la política para que las solicitudes antiguas sigan siendo explicables.
Paso 3: Crear un caso idempotente
Crea case_id, ID del sujeto, versión de la política, fecha límite y origen. Cada destino recibe el ID del caso y devuelve el mismo resultado ante repeticiones. Utiliza estados como solicitado, en ejecución, verificado, bloqueado, fallido y expirado.
Paso 4: Propagar a lo largo de las dependencias
Elimina el registro de origen o emite un tombstone, y luego activa a los consumidores de CDC para índices, cachés y almacenes derivados. Los sistemas por lotes necesitan una tabla de supresión para que los trabajos posteriores no recreen al sujeto. Los terceros confirman a través de un acuse de recibo por API o un proceso contractual.
Paso 5: Gestionar respaldos y borrado de claves
Los respaldos suelen expirar según un cronograma. Si las modificaciones individuales son imposibles, aísla el acceso a la restauración, mantén un manifiesto de eliminación y reaplica la eliminación durante la restauración. Las claves de cifrado por sujeto pueden hacer que el texto cifrado sensible sea irrecuperable tras la destrucción de la clave, pero esto no constituye un atajo legal universal.
Paso 6: Verificar más allá de los códigos de éxito
Los consumidores devuelven recuentos, versiones, particiones y sumas de verificación. El orquestador realiza lecturas de muestra en el almacén principal, el índice, el almacén de datos y el almacenamiento de objetos, y comprueba la invalidación de caché y las marcas de agua de CDC. Una verificación fallida crea trabajo de compensación en lugar de cerrar el caso.
Paso 7: Aislar excepciones de retención
Almacena los registros bajo retención legal por separado, con campos mínimos y excluidos de consultas de producto. El informe del caso contiene el alcance, la base legal, el propietario y la fecha de revisión. La liberación de una retención crea automáticamente una nueva tarea de eliminación; una excepción no puede convertirse en una lista negra permanente.
Paso 8: Auditar, alertar y responder
Los registros de auditoría contienen resúmenes criptográficos irreversibles del sujeto, el actor, la hora, la versión de la política y el resultado, no cargas útiles sensibles. Monitorea la antigüedad de los casos, la tasa de fallas, la cobertura del catálogo, las confirmaciones de terceros y los simulacros de restauración. Los usuarios ven un estado de completado, en procesamiento o retenido legalmente con un plazo claro.
Pseudocódigo del flujo de trabajo de eliminación
case = create_case(subject, policy_version)
for target in catalog.targets(subject, policy_version):
enqueue_idempotent(case.id, target, action_for(target))
verify_samples(case)
close(case, "verified" if all_verified(case) else "blocked")Compensaciones y límites
| Escenario | Estrategia | Costo |
|---|---|---|
| Principal e índice | Tombstone más eliminación asíncrona | Retardo de propagación |
| Agregado analítico | Eliminar detalle identificativo y recalcular | Costo computacional |
| Respaldo de larga duración | Expiración o reejecución de eliminación durante la restauración | No es un borrado inmediato de filas |
| Retención legal | Minimizar campos y congelar acceso | Revisión y gobernanza |
La prueba debe cubrir dónde buscó el sistema, qué destinos confirmaron y qué excepciones permanecen. No debe prometer una desaparición física inverificable. Google Cloud describe la eliminación como un pipeline por etapas en el que los datos permanecen protegidos hasta que las etapas se completan.
Plan de despliegue y evidencia
Elige un conjunto de datos de usuarios y conecta un catálogo, un mapa de identidad, el almacén principal, el índice y el almacén analítico. Inyecta mensajes duplicados, consumidores fuera de línea, restauración de respaldos y cambios de política. La Comisión Europea documenta las excepciones legales a la supresión; Google Cloud documenta la eliminación por etapas; la pregunta pública de diseño de TechInterview destaca microservicios, almacenamiento de objetos, analítica, respaldos y registros de auditoría.
Criterios de salida del piloto
La cobertura del catálogo es medible; cada destino tiene un propietario y una capacidad definida; las solicitudes repetidas son idempotentes; las fallas se reintentan o escalan; la verificación por muestreo detecta residuos; las retenciones tienen una base y una expiración; y el comprobante del usuario coincide con el estado interno.
Cómo demostrar que la ganancia es real
Compara conjuntos de datos no registrados, tiempo de finalización, tasa de residuos encontrados por verificación, tasa de reintentos e intervención humana antes y después. Realiza simulacros con consumidores fuera de línea, restauración de respaldos y tiempos de espera de terceros en lugar de medir únicamente el camino feliz.
Errores comunes y preguntas de seguimiento
Eliminar únicamente la fila principal
Los índices, cachés, almacenes de datos y almacenamientos de objetos aún pueden devolver datos. La cobertura del catálogo y las confirmaciones de recepción downstream deben ser criterios de finalización.
Un solo evento DELETE global para todos los sistemas
Los consumidores necesitan diferentes acciones y versiones. Sin idempotencia, confirmaciones de recepción y marcas de agua, los eventos pueden perderse o repetirse. Utiliza un flujo de trabajo basado en ID de caso.
Afirmar que los respaldos se borran de inmediato
Muchos respaldos expiran según un cronograma. Explica el aislamiento de acceso, los manifiestos de eliminación, la reejecución en la restauración y el tiempo final de sobreescritura.
¿Cómo evitan las retenciones legales bloquear todas las eliminaciones?
Minimiza el alcance retenido, congela el acceso, registra la base legal, el propietario y la fecha de revisión, y continúa eliminando todo lo que esté fuera de la retención.
¿Cómo se evita que los datos se vuelvan a crear?
Emite un tombstone en el origen o un registro de supresión; CDC y los trabajos por lotes comprueban el estado de eliminación antes de crear derivados, y la reejecución reaplica la política.
¿Qué ocurre si el usuario exige una finalización inmediata?
Distingue los destinos verificados de los pasos sujetos a plazos de respaldo o de terceros, devuelve el estado de procesamiento junto con una fecha límite, y nunca inventes un borrado físico ya completado.