Tema representativo de entrevista

Entrevista de diseño de sistemas: Diseñar un registro de recibos de consentimiento multiinquilino

Diseño de sistemasDifícil
Equipo editorial de Offer.ccPublicado Actualizado

Pregunta

Diseñe un registro de recibos de consentimiento multiinquilino que registre el consentimiento, la revocación y los cambios de finalidad, al mismo tiempo que admita consultas de auditoría.

Planteamiento y casos de uso

Diseñe un registro de recibos de consentimiento multiinquilino que registre el consentimiento, la revocación y los cambios de finalidad, al mismo tiempo que admita consultas de auditoría. Este planteamiento encaja en entrevistas de diseño de sistemas, ingeniería de privacidad e infraestructura de plataformas. La clave consiste en modelar el consentimiento como hechos trazables en lugar de un booleano sobreescribible.

Qué evalúan los entrevistadores

  • Si define eventos de consentimiento, versiones de finalidad, categorías de datos, evidencias y la semántica de revocación.
  • Si el aislamiento de inquilinos, la integridad de solo anexión (append-only), la idempotencia y las consultas verificables se diseñan en conjunto.
  • Si se gestionan la propagación de revocaciones, los consumidores retrasados, los reintentos y las correcciones históricas.
  • Si se equilibran la minimización de la privacidad, la auditabilidad, el rendimiento de las consultas y la retención.

Preguntas para aclarar antes de responder

Confirme si el sujeto es un usuario final o un administrador empresarial, y si el consentimiento se delimita por finalidad, categoría de datos, región o encargado del tratamiento. Pregunte sobre el volumen máximo de eventos, las dimensiones de consulta, los plazos de auditoría, el almacenamiento entre regiones, la inmediatez de la revocación y las confirmaciones de recepción posteriores. Aclare la exportación legible por máquina, la retención legal (legal hold), las solicitudes de eliminación y las claves administradas por el inquilino.

Marco de respuesta de 30 segundos

“Utilizaría finalidades versionadas y un flujo de eventos de solo anexión para otorgamientos, actualizaciones, revocaciones y resultados de propagación. Las escrituras están particionadas por inquilino y son idempotentes; las lecturas devuelven el estado efectivo y una cadena de evidencias en un momento determinado. Las revocaciones notifican a los encargados del tratamiento posteriores mediante una cola confiable con reintentos y revisión humana. El cifrado, los campos mínimos, las claves de inquilino y las políticas de retención limitan la exposición”.

Respuesta detallada paso a paso

  1. Modelo de dominio: defina el sujeto, el inquilino, la versión de finalidad, la categoría de datos, la fuente del consentimiento, el idioma, las marcas de tiempo, el texto de evidencia y las transiciones de estado.
  2. Escrituras e integridad: anexe eventos con una secuencia monotónica y una clave de idempotencia de solicitud; utilice una cadena de hashes o firmas contra modificaciones silenciosas, separando la rotación de claves del aislamiento de inquilinos.
  3. Lecturas de estado: cree proyecciones para consultas por sujeto y finalidad mientras conserva la posición del evento, la versión de la proyección y las referencias de evidencia.
  4. Propagación de revocaciones: publique la revocación a los encargados del tratamiento posteriores y registre la confirmación, el reintento y el error final de cada destinatario; «enviado» no debe significar «procesamiento detenido».
  5. Operaciones y gobernanza: particione los datos, organice el almacenamiento por niveles, audite el acceso, priorice la eliminación frente a la retención legal y proporcione exportaciones y paginación autorizadas por el inquilino.

Respuesta de muestra de alta calidad

Dividiría el registro en una capa de eventos inmutable, proyecciones reconstruibles y almacenamiento controlado de evidencias. Cada evento incluiría el inquilino, una referencia no reversible del sujeto, la finalidad y su versión, la categoría de datos, la acción, la fuente, la hora, la versión de la política y la clave de idempotencia de la solicitud. El texto original del consentimiento o una captura de pantalla de la interfaz de usuario residiría en un almacenamiento cifrado y se mantendría fuera de las consultas ordinarias. Los inquilinos tendrían particiones y alcances de claves independientes; los eventos se anexarían a una secuencia de inquilino y utilizarían hashes y firmas para detectar ediciones silenciosas. El servicio de consultas leería una proyección para obtener el estado efectivo en un momento seleccionado, y luego devolvería la posición del evento y la referencia de evidencia. Los eventos de revocación entrarían en una cola confiable y rastrearían la confirmación de recepción por cada encargado del tratamiento posterior. Los tiempos de espera agotados o los rechazos se reintentarían y escalarían, con estados explícitos para registrado, enviado, confirmado y fallido. Las proyecciones podrían reconstruirse desde el registro para cambios de versión de finalidad y correcciones históricas. Validaría el aislamiento de inquilinos, las solicitudes duplicadas, los eventos fuera de orden, la rotación de claves, la latencia de revocación, la autorización de exportaciones y las retenciones por eliminación mediante pruebas y simulacros de reproducción.

Errores comunes

  • Almacenar solo consent=true, lo que borra las versiones de finalidad y el historial de revocaciones.
  • Tratar el éxito de la notificación posterior como prueba de que el procesamiento se detuvo.
  • Reemplazar eventos de solo anexión con una fila editable, perdiendo la evidencia de los cambios históricos.
  • Colocar sujetos identificables o datos de inquilinos en un índice global, rompiendo el aislamiento y la minimización.
  • Diseñar escrituras sin considerar eventos fuera de orden, reintentos, reconstrucciones de proyecciones, eliminación o retención legal.

Preguntas de seguimiento y respuestas

¿Qué ocurre si un usuario hace clic en consentir dos veces?

Desduplique con una clave de idempotencia de solicitud y una huella digital del evento, conservando los cambios significativos de fuente o de versión de la interfaz de usuario. Devuelva el estado efectivo y preserve qué solicitudes se fusionaron o ignoraron.

¿Un cambio de versión de finalidad requiere un nuevo consentimiento?

Trate el texto de la finalidad y la versión como referencias inmutables. Si una nueva versión amplía el procesamiento, cree un estado de consentimiento nuevo requerido; no aplique silenciosamente el consentimiento antiguo a la nueva finalidad.

¿Cómo admite el registro las solicitudes de eliminación?

Separe la evidencia de auditoría que debe retenerse de los datos del sujeto que se pueden eliminar, utilizando referencias no identificativas y borrado criptográfico donde corresponda. La retención legal tiene prioridad sobre la eliminación ordinaria, registrando el alcance y las excepciones como eventos controlados.

¿Cómo demuestra que una consulta no omitió eventos?

Devuelva el rango de secuencias del inquilino, la versión de la proyección y el resumen de verificación de eventos. Una herramienta de auditoría puede reproducir la capa de eventos en el mismo punto y compararla con la proyección.

Fuentes públicas

Preguntas relacionadas

Herramienta de entrevista relacionada

Usa Resolver para una respuesta de diseño de sistemas

Aclara primero los requisitos y luego avanza a través de la escala, la arquitectura, la elección de componentes y las compensaciones (trade-offs).

Ver la herramienta