You are building a service catalog for your IDP. Your company has 200 microservices, and nobody knows who owns half of them. How do you fix this, and what does a good service catalog look like?

Question

Accepted Answer

A service catalog is the single source of truth for 'what do we run, and who owns it?' Without one, every incident starts with 20 minutes of Slack threads asking 'does anyone know who owns this service?'

Here is how I would fix the ownership mess:

First, require every service to have a catalog-info.yaml in its repo. This file declares the service name, owning team, dependencies, and API specs. If a repo does not have one, it shows up as 'unowned' in the catalog, which creates social pressure to fix it.

Second, automate catalog discovery. Do not rely on people manually registering services. Scan your GitHub org, pull in metadata from Kubernetes (what is actually running), and cross-reference with your cloud provider. If a service is running in production but is not in the catalog, flag it.

Third, make the catalog useful, not just a registry. A good service catalog shows: who owns this, what it depends on, its current health, recent deployments, on-call rotation, API docs, and cost. If the catalog is just a list of names, nobody will maintain it.

The ownership model matters too. Use team ownership, not individual ownership. People leave. Teams persist. And every service must have exactly one owning team. Shared ownership means no ownership.

Tools like Backstage, Cortex, or OpsLevel do this well, but you can start with a simple YAML file per repo and a script that aggregates them.

Service Catalog and Ownership

Sample answer

Why this matters

Code examples

Common mistakes to avoid

Likely follow-ups

More Platform Engineering interview questions

Also worth your time on this topic

Building an Internal Developer Platform from Scratch

Building an Internal Developer Platform from Scratch

Internal Developer Platform Purpose