Design a centralized model registry for a large enterprise

WHAT THIS TESTS: This tests whether you can design a platform service that decouples model artifacts from training frameworks and deployment targets while enforcing reproducibility and access control at enterprise scale. Interviewers want to see that you understand the difference between a file server and a governance layer, and that you can reason about metadata schemas, dependency hell, and multi-tenant isolation.

A GOOD ANSWER COVERS: First, immutable storage and versioning. Propose a content-addressable store for large binaries with semantic or calendar versioning for human-readable aliases, plus a metadata database that tracks lineage, training metrics, and approval workflows. Second, dependency management. Require each registered model to include a manifest specifying library versions, CUDA dependencies, and a base container image digest rather than assuming host environment compatibility. Third, API design. Recommend a framework-agnostic REST or gRPC API with paginated list endpoints, strong filtering by tags and frameworks, and role-based access control so teams remain isolated within their own namespaces. Fourth, deployment abstraction. Introduce a target-agnostic interface where the registry emits containerized artifacts or compiled formats like ONNX and TensorRT so that Kubernetes, edge devices, and batch pipelines consume the same source of truth without framework-specific coupling.

COMMON WRONG ANSWERS: A major red flag is suggesting a shared NFS folder or S3 bucket with loose naming conventions as the registry. Another is ignoring dependency management entirely and assuming the deployment environment will match the training environment. Proposing framework-specific APIs such as a PyTorch-only serving endpoint also signals a lack of platform thinking. Finally, omitting metadata search and lineage means teams cannot audit which production model came from which training run.

LIKELY FOLLOW-UPS: Interviewers often ask how you would handle schema evolution for model metadata without breaking existing clients, how to enforce immutability when a model artifact is terabytes in size, or how to design a promotion pipeline from staging to production. They may also probe how you would support A-B testing with multiple active versions or how to garbage collect unreferenced artifacts while respecting compliance retention rules.

ONE CONCRETE EXAMPLE: Imagine a computer vision team registers a model with version 2.3.1. The registry stores the ONNX binary in object storage under a SHA-256 key and writes a metadata record containing the training dataset ID, the Python 3.11 and CUDA 12.2 container digest, and approval signatures. When the deployment team requests the latest approved version for the edge fleet, the API returns a signed URL for the binary plus the exact container manifest, ensuring the edge compiler can reproduce the runtime without guessing dependencies.