The brief
Help product teams ship services without rebuilding infrastructure each time. Your design should meet these requirements:
- Teams can create services from supported templates.
- Standard deployment, observability, and ownership conventions are built in.
- Teams retain safe control over service-specific settings.
Scale to design for
An internal developer platform for hundreds of teams: create services from templates with deployment, observability, and ownership built in, while allowing safe customisation.
State these assumptions out loud in the interview, then let them drive your choices: they decide what needs caching, sharding or asynchronous processing.
Before you start
You'll get more out of this round if you're comfortable with:
- CI/CD pipelines
- Containers and Kubernetes
- Service templates
- Self-service vs guardrails
Questions an interviewer may ask
Expect follow-ups like these once your high-level design is on the board. Have an answer, and a reason, for each:
- How do 300 existing services get a security fix in the template?
- How does a team customise its deploy pipeline without breaking conventions?
- How do you measure platform success?
Common mistakes to avoid
- One-time scaffolding that drifts immediately
- No ownership metadata
- Blocking teams with no escape hatch
- A platform that is a ticket queue instead of self-service
Concepts this round covers
- Golden paths
- Self-service APIs
- Escape hatches
- Developer experience
What a complete answer covers
A platform control plane, service catalog, template lifecycle, and clear boundaries between platform and product teams.
There is no single correct design. A strong answer meets the requirements at the stated scale and explains the trade-offs behind each choice. New to the format? Read how to prepare for a system design interview.