Start with the decision#
Every production component needs a named team that can deploy, observe, respond, migrate, and retire it; shared infrastructure still requires explicit service boundaries.
Mechanism and state flow#
- Name the owning team and the user-facing promise.
- Define dashboards, alerts, runbooks, access, and escalation paths.
- Assign deploy, configuration, dependency, data, and incident responsibilities.
- Review readiness before launch and rehearse recovery.
- Transfer or retire ownership with documentation, training, access, and a dated handoff.
Concrete example#
Notification service
The product team owns templates and user preferences; the messaging platform team owns queues and worker runtime; a delivery team owns provider integrations and bounce handling. One severity matrix names who commands cross-boundary incidents.
Architecture consequence: No alert or migration lands in a gap between teams, and handoffs include permissions plus executable recovery knowledge.
Trade-offs#
| Option | Choose when | Cost or limit |
|---|---|---|
| Product-team ownership | Domain behavior changes frequently and tight feedback matters. | Operational expertise may be uneven. |
| Platform ownership | Many services share a stable capability. | Queueing, abstraction, and priority conflicts. |
| Shared rotation | A transition or coupled boundary genuinely requires both teams. | Ambiguous command unless responsibilities are explicit. |
Failure diagnosis#
- Failure
- A provider credential expires and every team assumes another team owns renewal.
- Impact
- Delivery stops while responders search for access and decision authority.
- Detection
- Unowned alerts, stale runbooks, expired access reviews, and incidents with repeated escalations.
- Mitigation
- Keep a component ownership map, expiration alerts, named primary and secondary rotations, and readiness checks that fail on missing owners.
- Trade-off
- Ownership metadata needs upkeep; missing ownership creates much larger incident toil.
Design checkpoint#
Work the scenario before revealing the checklist
- Map every stateful or externally managed component to one accountable team.
- Name deploy, rollback, on-call, data, and deprecation owners.
- Identify the highest-risk cross-team dependency.
- Define the evidence required before an ownership transfer completes.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- Who owns a shared schema migration?
- What happens when the owning team is unavailable?
- How do you retire a component without leaving data or alerts behind?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Evolving the SRE Engagement ModelGoogle SRE
- Incident Management GuideGoogle SRE
Sources reviewed 2026-09-04. Validate product limits, legal obligations, and operational assumptions for the system you are designing.