system-design · advanced
Production-Readiness Reviews (PRRs)
Quick answer
A production-readiness review (PRR) is a pre-launch gate: SLOs, dashboards/alerts, rollback, capacity, security basics, on-call ownership, and runbooks. It complements architecture reviews by focusing on operability on day one.
Why this matters
- Launching without observability is flying blind.
- Rollback and ownership gaps turn small bugs into SEV1s.
- Staff engineers institutionalize paved-road launches.
Learning objectives
- Run a PRR checklist. 2. Separate launch blockers from follow-ups. 3. Verify SLOs and alerts exist. 4. Confirm on-call and runbooks. 5. Avoid checkbox theater.
Explain like I am 5
Before opening a lemonade stand, check cups, napkins, and a plan if you spill—not only the recipe.
Mental model
flowchart LR
Design --> PRR
PRR --> Blockers
PRR --> Followups
Blockers --> Launch
Followups --> Backlog
Core concepts
Checklist themes
SLIs/SLOs, golden signals, deploy/rollback, capacity, dependencies, security, privacy, docs, ownership.Blockers vs debt
No page-worthy alerts = blocker. Nice dashboard polish = follow-up.Paved roads
Platform templates should make PRR easy for standard services.Continuous readiness
Revisit after major redesigns, not only first launch.Worked example
New fraud scoring API: missing dependency timeout alerts = blocker; add burn-rate alert + runbook before prod traffic; flag UI polish as follow-up.
Trade-offs
| Heavy PRR always | No PRR |
|---|---|
| Slow experiments | Prod chaos |
Failure modes
| Mode | Mitigation |
|---|---|
| Rubber stamp | Independent reviewer |
| 100-page forms | Short blocker list |
| No owner | Named on-call |
Interview mode
Skeleton: "PRRs verify operability—SLOs, alerts, rollback, capacity, ownership—before real traffic."
Knowledge check
No actionable alerts or rollback path for a user-facing service
Imperfect slide aesthetics
Choosing TypeScript vs Java alone
Having too many unit tests
By Shubham Jain