Consigna y alcance
Esta pregunta evalúa el diseño del ciclo de vida y su comprobación, no un único DELETE. Rastree el identificador de un titular a través de objetos sin procesar, archivos de tablas, resultados derivados, cachés, características (features), exportaciones, registros (logs), instantáneas (snapshots) y respaldos. Defina cuándo el sistema puede afirmar honestamente que se ha completado el proceso.
La consigna no decide las obligaciones legales. Indique que los responsables legales y de privacidad definen las obligaciones de retención, las excepciones y los plazos; la ingeniería los transforma en un alcance ejecutable, estados y evidencia.
Qué evalúa el entrevistador
- Un inventario de datos y un linaje que cubra copias, valores derivados, registros, instantáneas, cachés y respaldos.
- Una solicitud idempotente, reintentable y pausible que no pueda reintroducirse mediante la ingesta o la reproducción.
- Límites claros entre la invisibilidad lógica, el borrado físico, la expiración de instantáneas y la caducidad de respaldos.
- Aislamiento de consultas y entrenamiento durante la eliminación, con protección de inquilinos (tenants) y datos confidenciales.
- Evidencia que demuestre que se procesó cada alcance en lugar de un único booleano de éxito.
Estructura de respuesta recomendada
Defina la clave del titular, el estado de la solicitud y el contrato de finalización. Mapee los dominios y el linaje. Asigne un erasure_id estable, bloquee la ingesta y la reproducción para el titular, elimine o reconstruya cada dominio y luego ejecute comprobaciones independientes y limpieza de retención. Persista versiones de entrada, recuentos, fallas y cursores para que la recuperación se reanude sin efectos duplicados.
Análisis en profundidad: de la solicitud a la prueba
Definir primero el alcance y la identidad
Mapee identificadores de cuenta, dispositivo, pedido y externos a una clave de titular inmutable. Enumere objetos sin procesar, filas de Iceberg, agregados, características, índices, exportaciones, cachés, registros y respaldos. Los datos desconocidos o no rastreados se convierten en un elemento de riesgo explícito.
Hacer que el borrado sea mutuamente excluyente con la ingesta
El servicio de borrado registra un erasure_id y el estado del titular. Los trabajos de ingesta, reproducción y derivación verifican el marcador de eliminación antes de escribir. Una lápida (tombstone) o una barrera de partición del titular bloquea los eventos antiguos, mientras que las versiones o los arrendamientos (leases) evitan que una instantánea más antigua se confirme después del borrado.
Separar la eliminación lógica de la limpieza física
Los deletes por igualdad o posición en Iceberg pueden ocultar filas a las lecturas mientras los archivos antiguos, las instantáneas y los archivos huérfanos aún existen. Programe la compactación, la expiración de instantáneas y la limpieza de archivos huérfanos dentro del período de retención. Elimine los objetos sin procesar a partir de un inventario. Para los respaldos, registre reglas de restauración controlada y una tarea de eliminación por caducidad.
Los datos derivados no se pueden solucionar eliminando solo las entradas
Recalcule los agregados rastreables por titular. Para los agregados que no se puedan rastrear hasta el origen, conserve el estado intermedio a nivel de titular o reconstruya la partición. Los propietarios de características, cachés y exportaciones deben limpiar sus versiones; pause la publicación durante el borrado y reconstruya a partir de entradas saneadas.
Definir la finalización con evidencia
Para cada dominio, registre el alcance del escaneo, el recuento de coincidencias, la versión de eliminación, el trabajo de limpieza física, las fallas y la hora de verificación. Las rutas independientes de consulta, exportación y reproducción no deben devolver ningún titular objetivo. La falta de evidencia significa finalización parcial, no éxito.
Respuesta de ejemplo
“Primero confirmaría la clave del titular, las excepciones de retención y la fecha límite con el responsable de privacidad. El servicio de borrado crea un erasure_id idempotente, bloquea la ingesta y la reproducción, y escribe un elemento de trabajo para cada dominio. Los objetos sin procesar se eliminan a partir de un inventario. Iceberg recibe primero un delete por igualdad, luego la compactación y la expiración de instantáneas; los agregados y las características se reconstruyen por titular, mientras que los propietarios de cachés y exportaciones limpian sus versiones. Los respaldos solo permiten restauraciones controladas y reproducen la lápida antes de su liberación. Cada paso registra versiones, recuentos y fallas. La solicitud pasa a completada únicamente cuando hay cero coincidencias en todos los dominios y ninguna falla sin resolver.”
Modos de fallo comunes y soluciones
- Eliminar solo la tabla principal → Enumere las copias sin procesar, derivadas, de caché, de exportación, de registro y de respaldo.
- Llamar borrado físico a los delete files → Explique las instantáneas, los archivos antiguos, la compactación y la limpieza de archivos huérfanos.
- Ignorar las escrituras concurrentes → Agregue barreras, lápidas, comprobaciones de versión y compuertas de reproducción.
- Usar una sola bandera de éxito → Persista el alcance por dominio, los recuentos, las versiones y las comprobaciones independientes.
- Prometer la reescritura inmediata del respaldo → Especifique la retención, los controles de acceso, la limpieza por caducidad y las excepciones aprobadas.
Rúbrica de evaluación y autocomprobación
Las respuestas sólidas incluyen una identidad estable, un linaje completo, una máquina de estados idempotente, barreras de escritura y reproducción, límites lógicos/físicos, reconstrucciones de derivados, manejo de respaldos, recuperación de fallas, evidencia por dominio, verificación de cero coincidencias, aislamiento de inquilinos y minimización en la auditoría.
Pregúntese: ¿Conozco al propietario de cada copia? ¿Puede volver a entrar un evento antiguo? ¿Qué datos están ocultos versus borrados? ¿Cómo consume la reproducción una lápida? ¿Cómo se reanuda tras una falla? ¿Qué evidencia cambia el estado de finalización?
Preguntas de seguimiento y extensiones
¿Qué pasa si la tabla de Iceberg es demasiado grande para reescrituras de archivos inmediatas?
Escriba una eliminación a nivel de fila para que las lecturas excluyan al titular de inmediato, luego programe la compactación según la densidad de eliminaciones y la fecha límite de retención. Mientras tanto, restrinja el acceso a instantáneas y exportaciones, y mantenga el tiempo de limpieza física en el estado.
¿Qué sucede si la eliminación y un nuevo evento llegan al mismo tiempo?
Utilice una barrera por titular o una versión monótona para rechazar o poner en cuarentena nuevos eventos hasta que se complete el borrado. La reproducción debe verificar la lápida; solo un evento explícitamente más nuevo y permitido puede pasar después de la liberación.
¿Qué pasa si una métrica derivada no se puede rastrear hasta los usuarios?
Marque el dominio como no demostrable, pause la publicación y elija un estado intermedio a nivel de titular, la reconstrucción de la partición o una alternativa aprobada. Sin evidencia de linaje, no declare la eliminación.
¿Cómo se evita que el registro de auditoría filtre datos personales?
Almacene una referencia de titular irreversible, el ID de solicitud, el alcance y los recuentos, no nombres, correos electrónicos ni el contenido del evento. Proteja el acceso a la auditoría por separado y alinee su retención con la política de privacidad.