hardDesignScenarioSeniorStaffLead
You've built a service catalog with an owner field on every entry. A year later, half the owners listed are people who left the company. How would you design the catalog so that doesn't happen?
4 min readUpdated 2026-08-15
Answer
Short answer
Treat ownership as a derived, continuously verified fact rather than a manually entered field: source it from an existing system of record, expire it on a schedule, and fail builds or pages loudly when it goes unverified.
The practical backstage test is whether the service catalog ownership data goes stale answer gives the interviewer something concrete to challenge.
Was this answer helpful?
Likely follow-ups
- How would you retrofit this onto a catalog that already has a thousand stale entries?
- What do you do when a team genuinely has no clear owner, such as a shared library six teams depend on?
- How does this change if the source of truth you're deriving ownership from is itself sometimes wrong?
- What's the smallest version of this you'd ship first, and what would you deliberately leave out?
Related questions
- Six months after launching an internal developer portal, weekly active usage has plateaued at around forty percent of engineering. How would you go about figuring out why, and what would you actually do about it?hardAlso on backstage and platform-engineering4 min
- When you build a golden-path template for scaffolding new services, you're pushing every team toward one way of doing things. What do you gain from that, and what do you have to give up?mediumAlso on backstage and platform-engineering4 min
- A small percentage of your transaction reports are rejected every day and the team resubmits them the next morning. Is that acceptable?hardAlso on data-quality6 min
- An upstream team renames a field in the events you consume and nobody tells you. What should your pipeline have done?hardAlso on data-quality5 min