SLOs, error budgets, and criticality tiers
From 0.3: availability is defined per flow, and serial chains multiply. From 1.14: the failure inventory. SLOs and budgets turn both into a governing system.
The obvious design is to assign the same reliability target to every service so governance appears consistent. It makes the happy path simple, but it protects the wrong property. Reliability targets and error-budget policy must follow user flows and criticality, including the availability consumed by synchronous dependencies.
An SLI is a measured ratio of good events to total events for a user-visible flow: "fraction of ride requests that receive a driver offer within 10 s." An SLO is the target on that ratio over a window: 99.99% over 30 days. The error budget is the complement — 0.01%, about 2,000 of 20 M daily trips — and it is a spending account: releases, experiments, and risky migrations spend it; when it's exhausted, feature launches stop and reliability work takes priority. This single feedback loop is what keeps "move fast" and "four nines" from being a contradiction: the budget converts reliability from a value into a currency.
Not every flow deserves four nines. We tier once, here, and every subsequent lesson references the tier table instead of re-arguing it (CLT: pre-training the classification so later lessons compose it for free):
| Tier | Flows | SLO | Rationale |
|---|---|---|---|
| T0 — exchange core | Location ingest, nearby query, dispatch/offers, trip state transitions | 99.99% → 99.999% in Part 3 | Down = the marketplace does not exist. No revenue, stranded users. |
| T1 — transaction adjacent | Quotes, payment authorize/capture, login, notifications for offers | 99.99% | Down = degraded exchange: rides happen but poorly. |
| T2 — experience | History, ratings, receipts, chat, support console | 99.9% | Down = annoyance; retries and patience absorb it. |
| T3 — internal | BI, warehouse, reporting, experimentation | 99.5% | Down = analysts wait. Never allowed to touch T0–T2 paths. |
flowchart LR
SLI["SLI — measured: good events ÷ all events per flow"] --> SLO["SLO — target: 99.99% over 30 d"]
SLO --> EB["Error budget — 0.01% ≈ 4 m 23 s or 2,000 trips"]
EB --> SPEND{"Budget remaining?"}
SPEND -- "yes" --> SHIP["Ship features, run experiments, take risk"]
SPEND -- "no" --> FREEZE["Freeze launches — reliability work only"]
SHIP --> SLI
FREEZE --> SLI
SLOs on services instead of flows recreate the green-dashboard lie: five services each meeting 99.99% can compose into a flow that doesn't (0.3's multiplication trap). Measure the flow at the edge — as close to the rider's thumb as you can get.