Consigna y contexto
Diseña un registro donde los equipos publiquen y descarguen paquetes, imágenes de contenedor o artefactos de compilación. Cubre metadatos, blobs binarios, etiquetas de versión, permisos, disponibilidad, almacenamiento en caché, revocación y auditoría.
Elige primero una forma de artefacto y explica qué abstracciones se generalizan. Las restricciones principales son una copia por resumen de contenido (digest), ninguna versión parcialmente visible y la verificación del cliente de que los bytes no fueron reemplazados.
Qué está evaluando el entrevistador
Metadatos frente a contenido
Una respuesta sólida separa los metadatos de paquete, versión, etiqueta, dependencia y firma de los blobs de contenido inmutables, de modo que las lecturas de metadatos no analicen archivos grandes.
Semántica de versiones y consistencia
Explica el versionado semántico, las etiquetas móviles, las publicaciones concurrentes y la eliminación. Un mal mecanismo de resolución hace que las compilaciones no sean reproducibles.
Distribución y costo
Analiza las cargas fragmentadas (chunked uploads), la reanudabilidad, el direccionamiento por contenido, la CDN, la replicación entre regiones y la recolección de basura en lugar de limitarse a dibujar un almacén de objetos.
Seguridad y gobernanza
Los permisos, el aislamiento de inquilinos, la firma, el SBOM, el escaneo de malware, la auditoría y la revocación deben formar un único ciclo operativo.
Preguntas de clarificación que debes hacer
- ¿Se trata de un paquete tipo npm, una imagen OCI o un archivo de compilación arbitrario?
- ¿Cuáles son las tasas diarias de publicación/descarga y el almacenamiento total?
- ¿Puede moverse una etiqueta como latest?
- ¿Se puede sobrescribir una versión publicada o solo se puede continuar con una nueva versión?
- ¿Se requieren inquilinos privados, proxying upstream y recuperación multirregión?
- ¿La revocación bloquea nuevas descargas, elimina bytes o marca el riesgo conservando la evidencia?
Marco de respuesta de 30 segundos
“Comenzaría con un registro multi-inquilino y direccionado por contenido. El publicador sube y verifica los blobs, y luego confirma un manifiesto inmutable; las etiquetas solo apuntan a versiones existentes y se mueven bajo una condición de concurrencia. Un cliente lee los metadatos, obtiene los blobs por digest desde el almacenamiento de objetos o una CDN, y verifica el digest y la firma. Los permisos cubren espacios de nombres y acciones. La revocación marca el riesgo sin eliminar de inmediato la evidencia de auditoría. Los artefactos de alto tráfico usan CDN; la replicación, el escaneo y la recolección de basura se ejecutan de forma asíncrona”.
Análisis detallado paso a paso
Paso 1: Definir el modelo de recursos
Los recursos son espacio de nombres (namespace), paquete, versión, etiqueta (tag), manifiesto, blob, firma y procedencia. Un manifiesto hace referencia a digest, tipo de medio (media type) y tamaño; un blob es inmutable en ese digest.
Paso 2: Diseñar la publicación
El cliente solicita una sesión de carga y envía fragmentos al almacenamiento temporal. El servicio verifica cada fragmento y el digest final, y luego confirma atómicamente el manifiesto. Las sesiones expiradas se limpian; se reutiliza un digest existente.
Paso 3: Gestionar versiones y etiquetas
Una versión inmutable no se puede sobrescribir. Una etiqueta puede moverse, pero se registran el operador, los destinos antiguo y nuevo, y la versión condicional. La resolución de dependencias prefiere una versión y digest anclados por sobre latest.
Paso 4: Diseñar las descargas
Los metadatos devuelven el manifiesto, las dependencias y las firmas. La entrega de blobs admite solicitudes de rango (range requests), ETag y CDN. Los clientes verifican el digest; el digest es la clave de caché, mientras que la resolución de etiquetas tiene un TTL corto.
Paso 5: Escalar y recuperar
El almacenamiento de objetos guarda blobs grandes, mientras que los metadatos se particionan por espacio de nombres y paquete. Replica los manifiestos antes o junto con los blobs y expón una nueva región solo cuando se cumpla su política de lectura.
Paso 6: Asegurar y operar
Usa acciones de lectura, escritura, publicación, movimiento de etiquetas y eliminación con privilegios mínimos. Escanea malware, genera SBOM, verifica firmas y procedencia, y escribe cada acción en un registro de auditoría. Una versión revocada queda bloqueada para nuevas descargas mientras que la evidencia sigue la política de retención.
Respuesta modelo de alta calidad
“Dividiría el registro en metadatos, almacenamiento de blobs y tareas asíncronas de gobernanza. El cliente crea una sesión de carga fragmentada; tras la verificación del digest, una transacción confirma un manifiesto que hace referencia a blobs inmutables. Las versiones no se pueden sobrescribir; los movimientos de etiquetas usan una versión condicional y conservan el historial. Las descargas resuelven una versión anclada, la obtienen por digest desde la CDN o el almacenamiento de objetos y verifican las firmas.
El almacenamiento en caché direccionado por contenido y las solicitudes de rango reducen el costo de los blobs calientes. Los trabajos en segundo plano replican entre regiones, escanean malware y adjuntan SBOM y procedencia. Los espacios de nombres privados aplican permisos y cuotas por inquilino. La revocación marca una versión como bloqueada, detiene nuevas descargas y alerta al sistema de compilación sin eliminar la evidencia de auditoría. Monitorearía el éxito de las publicaciones, la latencia p95 de descarga, la tasa de aciertos de caché, el retraso de replicación y el acceso no autorizado”.
Errores comunes
- Permitir que los clientes muten el almacenamiento de objetos → se eluden los permisos y la integridad → usa sesiones de carga de corta duración y confirmación de manifiestos del lado del servidor.
- Permitir la sobrescritura de una versión publicada → las compilaciones no se pueden reproducir → haz que las versiones sean inmutables y publica una nueva versión.
- Usar latest como clave de caché permanente → los bytes varían silenciosamente → almacena en caché por digest y resuelve etiquetas con un TTL corto.
- Almacenar solo bytes → se pierden dependencias y firmas → persiste manifiestos estructurados y procedencia.
- Hacer que cada región sea legible de inmediato → los artefactos parciales se vuelven visibles → condiciona las lecturas al estado del manifiesto, los blobs y las políticas.
- Eliminar artefactos revocados → la evidencia de auditoría e incidentes desaparece → márcalos como bloqueados y limpia de forma asíncrona según las reglas de retención.
- Comprobar solo el inicio de sesión → el acceso entre inquilinos puede filtrarse → autoriza el espacio de nombres, la acción y el artefacto en cada límite.
- Bloquear la publicación durante los escaneos → la latencia de carga se dispara → pon en cuarentena primero, escanea de forma asíncrona y luego cambia el estado de disponibilidad.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: Dos publicadores mueven la misma etiqueta concurrentemente. ¿Qué sucede?
Usa una versión condicional o compare-and-swap. Devuelve la versión actual ante un conflicto para que el cliente reintente con el historial visible; nunca uses silenciosamente 'last-write-wins'.
Pregunta de seguimiento 2: ¿Cómo garantizas descargas completas?
El manifiesto declara digest, tamaño y tipo de medio. El cliente verifica el digest y reintenta con otra réplica si falla; el servicio monitorea los fallos de verificación.
Pregunta de seguimiento 3: ¿Puede continuar la publicación mientras la replicación tiene retraso?
La región primaria puede aceptar la publicación y marcarla como en replicación. Una región de destino solo la anuncia después de que los manifiestos requeridos, los blobs de dependencia y el estado de las políticas sean consistentes.
Pregunta de seguimiento 4: ¿Cómo recolectas la basura de blobs duplicados?
Crea un conjunto de referencias a partir de manifiestos activos, firmas y políticas de retención. Marca los blobs no referenciados, espera durante un período de gracia, vuelve a verificar la concurrencia y luego elimina.
Pregunta de seguimiento 5: ¿Cómo afecta la procedencia a las decisiones de descarga?
Asocia firmas, SBOM y procedencia con el manifiesto. Un motor de políticas decide si permitir, poner en cuarentena o alertar en función del inquilino, el entorno y el riesgo del artefacto.
Fuente 1: OCI Distribution Specification
La especificación OCI centra la distribución en manifiestos, descriptores y blobs, y define la semántica de push, pull, digest y errores para un registro direccionado por contenido.
Fuente 2: Metadatos de npm Registry
Los metadatos de npm Registry muestran las versiones, los dist-tags y la información del paquete como aspectos separados, lo que admite distintas reglas de consistencia y almacenamiento en caché para etiquetas y versiones inmutables.
Fuente 3: Integridad de la cadena de suministro de SLSA
La introducción de SLSA de Google enfatiza la procedencia, la trazabilidad y la resistencia a la manipulación indebida de los artefactos. Esas señales pueden alimentar la firma del registro, el SBOM, el escaneo y la política de descarga.