How the interviewer opens it
“Design a model registry for teams that store model artifacts and manage approval and release. Preserve lineage and support safe promotion and rollback.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Users and permissions
- Request volume
- Artifact volume
- Version identity and lineage
- Approval rules
- Promotion and rollback
- Latency
- Consistency and durability
- Retention
- Scope boundaries
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Register model versions and retrieve their artifacts
- Record each version's code, dataset, and training run references
- Approve versions for release
- Promote and roll back releases without bypassing approval rules
Usually out of scope
- Train models or run evaluations
- Serve predictions or control deployment traffic
- Store source datasets
- Build a model security scanner
What interviewers ask about
- Artifact publication
- Large uploads can stop midway. A published version must retain exact bytes despite retries, later uploads, and a zone failure.
- Approval decisions
- Approval must identify exact content and an authorized reviewer. Concurrent revocation and release requests must produce a clear result.
- Release changes
- Concurrent promotions and retries can select the wrong version. A zone failure must not erase an acknowledged release or its audit record.
- Lineage and retention
- Artifact deletion must preserve release safety and useful lineage. External dataset references can disappear even when registry records remain.
Common mistakes
- Treating a model version as a mutable directory
- Using one status field for artifact readiness, approval, and release
- Checking approval separately from the release change
- Assuming high availability guarantees durability without defining cross-zone acknowledgment rules
- Claiming that a registry rollback also restores deployment traffic
- Deleting artifacts without checking retained releases
The bar by level
- Senior (L5/E5)
- Handles partial publication, request retries, concurrent release changes, and approval revocation. Defines cross-zone acknowledgment requirements for metadata and artifacts. Connects retention to rollback safety. Separates registry state from deployment state.
- Staff (L6+/E6+)
- Defines transaction boundaries across approval, release, audit, and deletion. Explains quorum behavior and safe failover after a zone failure. Establishes policy for rule changes and external lineage loss. Quantifies artifact cost and regional failure trade-offs.
Sources · 1 reference
These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.
SysRound · 1 record
No company association
Design a model registry
Reported date not specified
Source snapshot: Nov 12, 2026
View source