Prompt and context
Design a registry where teams publish and download packages, container images, or build artifacts. Cover metadata, binary blobs, version tags, permissions, availability, caching, revocation, and audit.
Choose one artifact shape first and explain which abstractions generalize. The core constraints are one copy per content digest, no partially visible release, and client verification that bytes were not replaced.
What the interviewer is testing
Metadata versus content
A strong answer separates package, version, tag, dependency, and signature metadata from immutable content blobs, so metadata reads do not scan large files.
Version and consistency semantics
Explain semantic versions, moving tags, concurrent publishes, and deletion. A bad resolver makes builds irreproducible.
Distribution and cost
Discuss chunked uploads, resumability, content addressing, CDN, cross-region replication, and garbage collection instead of drawing only an object store.
Security and governance
Permissions, tenant isolation, signing, SBOM, malware scanning, audit, and revocation must form one operational loop.
Clarifying questions to ask
- Is this an npm-like package, an OCI image, or an arbitrary build file?
- What are daily publish/download rates and total storage?
- May a tag such as latest move?
- Can a published version be overwritten, or only followed by a new version?
- Are private tenants, upstream proxying, and multi-region recovery required?
- Does revocation block new downloads, delete bytes, or mark risk while retaining evidence?
30-second answer framework
“I would start with a multi-tenant, content-addressed registry. The publisher uploads and verifies blobs, then commits an immutable manifest; tags only point to existing versions and move under a concurrency condition. A client reads metadata, fetches blobs by digest from object storage or a CDN, and verifies the digest and signature. Permissions cover namespaces and actions. Revocation marks risk without immediately deleting audit evidence. Hot artifacts use CDN; replication, scanning, and garbage collection run asynchronously.”
Step-by-step deep dive
Step 1: Define the resource model
Resources are namespace, package, version, tag, manifest, blob, signature, and provenance. A manifest references digest, media type, and size; a blob is immutable at that digest.
Step 2: Design publishing
The client requests an upload session and sends chunks to temporary storage. The service verifies each chunk and the final digest, then atomically commits the manifest. Expired sessions are cleaned; an existing digest is reused.
Step 3: Handle versions and tags
An immutable version cannot be overwritten. A tag may move, but the operator, old and new targets, and conditional version are recorded. Dependency resolution prefers a pinned version and digest over latest.
Step 4: Design downloads
Metadata returns manifest, dependencies, and signatures. Blob delivery supports range requests, ETag, and CDN. Clients verify digest; digest is the cache key, while tag resolution has a short TTL.
Step 5: Scale and recover
Object storage holds large blobs, while metadata is partitioned by namespace and package. Replicate manifests before or alongside blobs and expose a new region only when its read policy is satisfied.
Step 6: Secure and operate
Use least-privilege read, write, publish, tag-move, and delete actions. Scan malware, generate SBOM, verify signatures and provenance, and write every action to an audit log. A revoked version becomes blocked for new downloads while evidence follows retention policy.
Model high-quality answer
“I would split the registry into metadata, blob storage, and asynchronous governance jobs. The client creates a chunked upload session; after digest verification, a transaction commits a manifest referencing immutable blobs. Versions cannot be overwritten; tag moves use a conditional version and retain history. Downloads resolve a pinned version, fetch by digest from CDN or object storage, and verify signatures.
Content-addressed caching and range requests reduce hot-blob cost. Background jobs replicate across regions, scan malware, and attach SBOM and provenance. Private namespaces enforce tenant permissions and quotas. Revocation marks a version blocked, stops new downloads, and alerts the build system without deleting audit evidence. I would track publish success, p95 download latency, cache hit rate, replication lag, and unauthorized access.”
Common mistakes
- Letting clients mutate object storage → permissions and integrity are bypassed → use short-lived upload sessions and server-side manifest commit.
- Allowing overwrite of a published version → builds cannot be reproduced → make versions immutable and publish a new version.
- Using latest as a permanent cache key → bytes drift silently → cache by digest and resolve tags with a short TTL.
- Storing only bytes → dependencies and signatures are lost → persist structured manifests and provenance.
- Making every region readable immediately → partial artifacts become visible → gate reads on manifest, blobs, and policy state.
- Deleting revoked artifacts → audit and incident evidence disappear → mark blocked and clean up asynchronously under retention rules.
- Checking only login → cross-tenant access can leak → authorize namespace, action, and artifact at each boundary.
- Blocking publish on scans → upload latency spikes → quarantine first, scan asynchronously, then change availability state.
Follow-up questions and responses
Follow-up 1: Two publishers move the same tag concurrently. What happens?
Use a conditional version or compare-and-swap. Return the current version on conflict so the client retries with visible history; never silently use last-write-wins.
Follow-up 2: How do you guarantee complete downloads?
The manifest declares digest, size, and media type. The client verifies the digest and retries another replica on failure; the service monitors verification failures.
Follow-up 3: Can publishing proceed while replication lags?
The primary region can accept the release and mark it replicating. A target region advertises it only after required manifests, dependency blobs, and policy state are consistent.
Follow-up 4: How do you garbage-collect duplicate blobs?
Build a reference set from active manifests, signatures, and retention policies. Mark unreferenced blobs, wait through a grace period, recheck concurrency, then delete.
Follow-up 5: How does provenance affect download decisions?
Associate signatures, SBOM, and provenance with the manifest. A policy engine decides allow, quarantine, or alert based on tenant, environment, and artifact risk.
Source 1: OCI Distribution Specification
The OCI specification centers distribution on manifests, descriptors, and blobs and defines push, pull, digest, and error semantics for a content-addressed registry.
Source 2: npm Registry metadata
npm Registry metadata shows versions, dist-tags, and package information as separate concerns, supporting distinct consistency and caching rules for tags and immutable versions.
Source 3: SLSA supply-chain integrity
Google’s SLSA introduction emphasizes artifact provenance, traceability, and tamper resistance. Those signals can feed registry signing, SBOM, scanning, and download policy.