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”
Every engineering team has had this meeting. Product wants a new feature shipped yesterday. On-call is drowning in pages. Leadership asks "how reliable are we?" and nobody agrees on the answer. One team quotes uptime percentage. Another quotes error rate. A third quotes . They are all measuring different things, over different windows, with different definitions of "good."
SLO engineering exists to replace that chaos with one number the entire organization trusts. Google formalized the practice in the original Site Reliability Engineering book in 2016, after a decade of internal iteration at Gmail, Search, and YouTube. The insight that made it stick: reliability is not a binary. It is a budget. You decide how much unreliability you can afford, and that decision shapes every trade-off between features and stability.
Stripe, Netflix, Honeycomb, and Datadog all run variations of the same SLO framework today. The details differ. The core loop is identical: pick a metric the user cares about, set a target, measure against the target, and let the remaining gap drive decisions.
The vocabulary matters because most teams confuse these three terms, and the confusion creates real operational damage.
| Term | Full Name | What It Is | Example |
|---|---|---|---|
| SLI | Service Level Indicator | The raw measurement of user experience | 99.94% of requests returned 200 in under 300ms |
| SLO | Service Level Objective | The internal target for the SLI | We aim for 99.9% over a rolling 30-day window |
| SLA | Service Level Agreement | A contractual promise with financial penalties | If we drop below 99.5%, customers get credits |
The relationship is strict: SLI is what you measure. SLO is where you want the measurement to land. SLA is the external contract with money attached. SLO is always tighter than SLA, because you want internal alerts to fire before the contract is breached. Google recommends at least a 2x buffer between SLO and SLA.
An SLI that measures something engineers care about but users do not is useless as a reliability signal. CPU utilization at 80% tells you the machine is busy. It tells you nothing about whether the checkout page loaded in time. Good SLIs measure what the user actually sees: request success rate, at the 99th percentile, video start time, search result quality.
Honeycomb ships SLO templates out of the box that combine success rate and latency into a single SLI. A request counts as "good" only if it returned 200 AND completed in under the latency threshold. This combined metric catches the common failure mode where the service returns 200 but takes 8 seconds, which is technically a success but practically a failure.