SLIs, SLOs, and Error Budgets in a Distributed Ecosystem
An SLI is a quantitative measure of service behavior - best expressed as a ratio of good events to valid events (successful requests / all requests, requests under a latency threshold / all requests). An SLO is a target value for that SLI over a window (for example, 99.9% of requests succeed over a rolling 28 days). The error budget is 1 minus the SLO: the permissible amount of unreliability, converted into minutes or failed requests. An SLA is a business contract with consequences; it is usually looser than the internal SLO. Choosing SLIs means choosing what users actually experience: availability, latency, throughput, freshness, correctness, and durability for data systems.
In a distributed ecosystem the hard part is composition. A user-facing SLO should be defined at the edge or on the user journey, not averaged across dozens of microservices; measuring every internal service at 99.9% does not tell you whether the checkout flow works. Averaging averages and using mean latency hide the tail - prefer percentile-based ratios and count good events, not average durations. Dependencies in series multiply: three sequential dependencies each at 99.9% yield roughly 99.7% for the path, which the naive answer often misses; retries, caching, and graceful degradation are how real systems beat that arithmetic. Alerting should be multi-window burn-rate based (fast burn for pages, slow burn for tickets) rather than on raw thresholds.
Worked example: 99.9% over 30 days gives 0.001 × 43,200 minutes ≈ 43 minutes of budget. A 2% burn rate over one hour consumes about 1.2 minutes of budget - tolerable. A 14.4× burn rate consuming 2% of the budget in an hour triggers a page.
Traps: confusing SLO with SLA; setting 100%; defining dozens of SLOs nobody uses; no policy for what happens when the budget is gone.