We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Reliability Resilience
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Reliability Resilience
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Shopify's storefront engineering team published their performance budget in 2021, and it was the most impactful single document they produced that year. The page had a 200 millisecond p95 target. Six services contributed to every page load. Before the budget existed, every team assumed they were fast and someone else was slow. After the budget, every team had a written number: gets 20ms, edge API gets 40ms, auth gets 30ms, database query gets 80ms, render gets 30ms. Total: 200ms exactly.
The moment those numbers were written down, two things happened. First, the teams that were over budget had to optimize. Second, the teams that were under budget got credit for it, and their surplus became tradeable currency when another team genuinely needed more time. Performance went from a vague aspiration to an engineering constraint with the same weight as a unit test.
Google internally calls this budgeting and treats the allocation document as a binding commitment that survives team reorgs. Amazon's "you build it, you run it" culture means the budget page goes directly to the team that owns the service. Stripe enforces budgets in CI: a pull request that regresses a service beyond its allocated budget fails the build. The budget is not a guideline. It is a gate.
A performance budget starts with one number: the user-facing target. Everything else flows from that.
| Step | What Happens | Who Owns It |
|---|---|---|
| Set the page target | Product and engineering agree on a p95 SLO. For Shopify storefronts: 200ms. For Google Search: 200ms. For Stripe Dashboard: 1000ms | Product + engineering lead |
| Measure the current state | Instrument every service in the request path. Record p95 per service for two weeks | Each service team |
| Allocate slices | Divide the total budget across services. Slices must add up to exactly the target. No slack | Cross-team negotiation, facilitated by platform team |
| Enforce in CI | Every PR runs a performance benchmark for the affected service. Build fails if the service exceeds its slice | Each service team's CI pipeline |
| Monitor burn in production | Real-time dashboards compare measured p95 against budget per service. Burn rate alerts fire when the gap shrinks | Each service team's on-call |
| Renegotiate quarterly | Services grow features and need more time. The total stays fixed. One team gives, another takes | Quarterly cross-team review |
The cardinal rule: the total is fixed by the user experience. The slices are negotiated. If auth needs 50ms instead of 30ms, another team must give 20ms back. Maybe the database team just shipped an index optimization and can spare the time. The shared document tracks every trade.