Hide outline
Feedback
Guide
Was this lesson helpful?
Dive Deeper
Generate a follow-up sub-lesson on any aspect of this topic
Guide complete
Reliability Targets: SLIs, SLOs, SLAs, And Nines
Generate a follow-up sub-lesson on any aspect of this topic
Reliability Targets: SLIs, SLOs, SLAs, And Nines
TLDR;
- A checkout API can look up while still failing real purchases, depending on how you measure success.
- Each extra nine cuts allowed downtime to a size that changes what incidents feel like operationally.
- An error budget turns reliability into a pacing lever for launches, risk, and when to slow down.
An online store’s checkout API is “available” only when a shopper can place an order and get a confirmed result, not when a server simply responds to pings. In a small, single region setup, traffic hits a load balancer, which forwards requests to the checkout service, which writes to a database and talks to a payment provider. At 200k checkouts per day, even short brownouts show up as abandoned carts, support tickets, and sometimes duplicate charges when clients retry. The business problem starts when expectations reach 99.9 percent and above because the remaining 0.1 percent is now a small, expensive slice of time and requests. Let’s ground the checkout request path we are actually promising to users.
In the diagram, the key dependency chain is client to load balancer to checkout service to database, plus the payment provider hop. The important numbers are the steady volume at 200k checkouts per day and the constraint that orders cannot be silently lost. That combination is why reliability targets need to be defined from the user’s request path rather than from a single machine’s health.
Availability becomes measurable when we define a good event as an outcome a shopper would accept, count those outcomes, and divide by all eligible events in a fixed window. For checkout, a good event is typically an HTTP 2xx that represents a completed purchase with a persisted order and an authoritative payment outcome, not merely that the process stayed up. This is why time based uptime can mislead because the host can be up while the database is timing out and users are failing, and request based availability can mislead if we exclude the hardest requests or count cached responses that do not represent a real order. The availability SLI is usually expressed as over 28 days so we can compare months consistently. Let’s see how the reported number changes when the outage is partial.
The tuning view makes the difference visible between time based uptime and request based success for the same incident. A partial outage that affects only some requests, such as a payment provider degradation that causes 10 percent of checkouts to fail, barely moves an uptime metric but sharply drops a request based metric. The takeaway for checkout is that user perceived availability lives at the request layer, measured where user harm happens.
Nines are just a way to talk about the complement of availability, which is allowed unavailability in a window. If availability is , then downtime fraction is , so allowed downtime in minutes is . The reason this matters is that humans reason better about minutes of pain than decimals. A target of 99 percent sounds close to 99.9 percent, but operationally it changes how often the team can be down without breaking its promise. Let’s convert common targets into minutes you can actually spend.
The table makes the scale shift obvious. Moving from 99.9 percent to 99.99 percent cuts allowed downtime by 10 times in the same window, turning a tolerable monthly incident into something that consumes most of the budget. For checkout, that difference often forces design changes because a few dependency hiccups per month can already exceed the tighter target.
A Service Level Indicator (SLI) is a specific metric that represents how users experience the service, measured at a defined point. For checkout, SLIs usually need to cover more than one failure shape because users can be harmed by outright errors, slowness that causes abandonment, or incorrect totals that create support and refund work. A practical set of candidate SLIs for checkout is:
p95 end to end request time for POST /checkoutThe mapping highlights that timeouts, 5xx, and failed payment attempts cluster under success rate, while slow database queries and upstream slowness show up most clearly in latency. Incorrect totals sit in a different bucket because the system can be fast and return 2xx while still creating real harm. For checkout, this is why many teams define success rate first, then add latency and correctness SLIs as separate guardrails rather than trying to compress everything into one number.
A Service Level Objective (SLO) is a target for an SLI over a stated time window that the team actively manages to. For checkout, an example pair is 99.9 percent success over 28 days and p95 latency under 300 ms over the same 28 days, measured at the load balancer for external requests. The window matters because a 28 day rolling window dampens one bad hour but still makes frequent small regressions visible. The target matters because it becomes the line that triggers operational tradeoffs such as turning off a risky feature flag or delaying a migration. Let’s compare two plausible SLO sets and what each forces the team to optimize.
The comparison makes the tension explicit between stricter latency and higher success. A success heavy SLO tends to push investment into dependency resilience, retries with limits, and failover, while a latency heavy SLO pushes caching, query tuning, and load shedding to keep tail latency down. For checkout, the cost is often paid in on call load because tighter targets amplify the number of alerts and the number of changes that require careful rollout.
Design rule
Treat an SLO as a control surface for tradeoffs, not a report card.
A Service Level Agreement (SLA) is an external commitment that usually includes measurement rules, exclusions, and consequences such as service credits. For checkout, an SLA might promise 99.9 percent monthly availability for the hosted store platform, excluding planned maintenance and force majeure, and measured at the provider edge. That SLA can be looser than the internal SLO because the external promise needs room for unknowns, and it may also be narrower in scope, such as covering only the API endpoint and not third party payment authorization. Let’s scan the parts that make an SLA enforceable and see how they differ from an internal SLO.
The checklist structure shows how scope, exclusions, and measurement point change the meaning of the same percentage. An internal SLO might count a payment provider outage as a checkout failure because users cannot buy, while an external SLA might exclude third party failures to limit legal exposure. For checkout, the practical result is that the on call team should still run to the internal SLO because that is the one aligned with user experience and revenue, even if the external SLA is easier to satisfy.
An error budget is the allowed amount of failure implied by an SLO, treated as something the team can spend on risk. If checkout has an SLO of 99.9 percent success over 28 days, the failure budget is 0.1 percent of eligible requests in that window. With 200k checkouts per day, a 28 day window has 5.6 million checkouts, so the budget is failed checkouts. This framing connects incidents and deployments because an incident that causes 2,000 failed purchases is not just an outage story, it is 36 percent of the month’s budget. Let’s compute budget in both failed requests and minutes, then see how it gets consumed.
The estimator ties the same SLO to two currencies, failed requests and unavailability minutes, so different teams can reason about it. After one or two incidents, the remaining budget shrinks enough that the safest decision can be to slow the feature release cadence, tighten canary thresholds, or freeze risky migrations until the window rolls forward. For checkout, this is where reliability becomes a business pacing tool because it makes the cost of additional risk legible and comparable to shipping pressure.
Reliability targets work when they describe the end to end checkout experience, but they break down when dependencies dominate the failure rate and the metric hides it. Payment providers, the primary database, and even internal DNS can determine whether checkout succeeds, even if the checkout service code is perfect. In that world, a single service SLO can turn into blame shifting unless it is paired with dependency SLIs and a clear stance on what is in scope for the promise. Let’s reveal the common dependency trap and how a dependency aware SLO changes the conversation.
The dependency view makes it clear which upstreams actually consume the error budget, often more than the checkout service itself. The redesign trigger is not that the number is hard, it is that the system architecture cannot meet the objective without changing the dependency story. For checkout, that typically means adding redundancy, such as multi region failover for the database, multiple payment routes, or queue based order capture that can complete asynchronously, and then writing SLIs that measure the whole path instead of a single box.