Prompt and context
This platform system-design question stores components, systems, domains, APIs, owners, and dependency edges from repositories, deployment systems, and human declarations. It serves discovery, incident response, and governance; it must not become another hand-maintained CMDB that nobody trusts.
What the interviewer evaluates
- Turning “find the service owner” into an entity model, source trust policy, and searchable experience.
- Handling conflicts, expiry, and deletion between declarative metadata and automated scans.
- Explaining dependency queries, permission isolation, tenant boundaries, and freshness SLOs.
- Choosing a staged platform rollout that balances value against maintenance cost.
Clarifying questions to ask
Confirm entity count, daily change volume, metadata delay, query peaks, organization or customer isolation, whether dependencies are static or runtime-observed, and who can declare ownership. High-risk incident use requires source levels, stale markers, and audit; a developer directory can start with looser freshness.
30-second answer framework
I would model a declarative entity graph: components, systems, domains, APIs, teams, and relations have stable identities. Repository catalog files provide intent; deployment and runtime signals add versions and observed edges; collectors write versioned events. A query service serves owners, reverse dependencies, and search while showing source and update time. Conflicts become actionable status instead of silent overwrites. Permissions apply to entities and fields, and stale entities remain historical but disappear from default results.
Step-by-step deep answer
1. Model entities and relations
Backstage’s entity model is a useful reference: components belong to systems, systems to domains, APIs are provided or consumed by components, and teams own components. Give every entity a stable name, namespace, and version key. Relation edges carry source, discovery time, and confidence. Ownership must reference a resolvable team principal, not free text, so incident routing can be automated.
2. Set capacity and SLOs
Assume 10,000 entities with 20 relations each, roughly 200,000 edges, and 5% daily entity changes, about 500 imports. Write through an event queue and maintain a read model with owner and adjacency indexes. A starting target could be import visibility within minutes, search P95 below 300 milliseconds, and three-hop dependency queries within one second; high-risk views also show data age.
3. Design ingestion and source precedence
Repository declarations provide intent and ownership, deployment systems provide actual versions and environments, and runtime telemetry supplies recent call edges. Each import stores source, commit version, and validation result and uses an idempotency key. Merge conflicts by field policy: one runtime observation cannot rewrite declared ownership, and a runtime edge cannot prove that a dependency does not exist. Put conflicts in a queue and notify owners.
4. Define freshness and deletion semantics
Store lastSeenAt, declaration version, and expiry policy per entity. Mark an entity stale after its sources stop updating; hide or demote it in default search while preserving history for incident replay. Repository deletion, service retirement, and ephemeral environments need different states. Immediate deletion destroys history; never deleting pollutes search. A periodic reconciler retries failed imports and removes orphan edges.
5. Build query, permission, and security paths
Support search by name, team, domain, environment, tag, and owner. Bound dependency depth and result count so graph traversal cannot overload the service. Attach organizational scope to entities and fields; redact sensitive repository paths, internal endpoints, and customer-tenant details by field. Audit ownership changes and denied access; hiding data in the browser is not authorization.
6. Ship progressively and keep alternatives
Stage one covers critical services and owner search with source and freshness requirements. Stage two adds dependency graphs, deployment versions, and incident routing. Stage three evaluates automated governance. If teams do not maintain declarations, start with repository templates and CI checks instead of a company-wide catalog. Amazon’s PM guidance emphasizes customer problems and competency evidence; adoption should be proven by search success, incident localization time, and metadata maintenance rate.
Model high-quality answer
I would treat the catalog as an entity graph with source and freshness, not as a spreadsheet. Components, systems, domains, APIs, teams, and relations have stable keys; repository declarations define intent, deployment adds environment versions, and runtime signals add recent dependencies. Collectors are event-driven and idempotent and retain commit versions. A read model serves owners, reverse dependencies, and bounded graph queries. Conflicts become a queue, stale entities remain historical but disappear from default search, and permissions apply by organization and field. I would prove search success, incident localization time, and maintenance rate on critical services before expanding.
Common mistakes
- Building a hand-maintained CMDB → it becomes stale quickly → use repository declarations and automated collection as facts.
- Storing owner strings → notifications and offboarding cannot be validated → reference resolvable team principals.
- Letting the newest source overwrite everything → runtime noise rewrites governance facts → rank sources and preserve conflicts.
- Deleting retired services → incident replay loses dependencies → use lifecycle states and historical versions.
- Unbounded dependency traversal → one query expands to the whole graph → bound depth and results and use adjacency indexes.
Follow-up questions and responses
What if declared ownership conflicts with deployment data?
Represent them as separate sourced attributes, merge by field policy, and show the conflict. Controlled declarations own the owner field; the deployment system owns environment fields. Notify both parties and resolve through a corrective commit.
How do you handle short-lived preview environments?
Give entities an environment and expiry. Preview entries receive low default weight and are archived automatically. If production depends on one, runtime edges can raise an alert, but ownership and tenant authorization still apply.
What happens if the catalog is unavailable during an incident?
Keep exportable snapshots and a recent owner cache for critical services and display their age. Incident tooling may read a snapshot, but must not present an expired snapshot as live truth.
How do you stop teams from treating the catalog as a release approval gate?
Start with discovery and incident response and measure search and localization time. Connect governance checks only after metadata and permissions stabilize; a failed check should provide a repair path rather than blocking every release.