Provider SLO Pass-Through

An internal authentication service achieves about 99.99% availability and publishes an SLO of 99.9%. Forty product teams consume it. Each builds a cache or a degraded mode against the published number, and most of that code will never execute. The product teams complain; the platform team points at its SLO.

Both are right, and the disagreement is about who pays for headroom. The gap between published and achieved is the platform's room to change things, and it is paid for in fallback code written forty times over.

Why it matters

The published number propagates. Every consumer computing its own journey availability uses the published figure, so if the platform publishes what it hopes rather than what it commits to, forty downstream calculations are wrong in the same direction. Publishing conservatively is therefore correct, and it is not free.

The cost lands somewhere specific: forty similar fallback implementations, each adding complexity to a critical path, and each untested, because a fallback that never fires in production is untested code in the request path. The reliability risk of the fallback can exceed the risk it was written against.

There is also an incentive asymmetry worth naming. The platform team captures the benefit of a wide gap and pays none of its cost, so the gap tends to widen over time unless somebody measures it.

And there is a trust effect: consumers who observe 99.99% will design against what they observe, which returns the situation to where publishing the achieved figure would have put it, with the added problem that nobody says so.

Implementation patterns

• Publish two labelled numbers: the commitment, which consumers may design against and on which the error-budget policy is enforced, and the recent achieved figure, as information. The gap becomes visible and arguable.
• Make the fallback a platform deliverable. If forty teams need the same degraded behaviour, ship a client library with the cache and the degraded path built in, tested by the platform team and exercised in its own game days. One tested implementation instead of forty untested ones.
• Offer tiers and price them. A consumer whose journey genuinely needs more can ask, and the platform can quote what it costs — more capacity, more replicas, tighter change control. That turns an argument about a number into a conversation about who funds headroom.
• Do the chain arithmetic before defending the gap. If consumers already depend on 4 other services at 99.9%, their journey is about 99.6% regardless, and the published gap is protecting a decimal nobody can observe.
• Rehearse the consumer fallbacks in the platform's game days, because the platform is the only party that can create the failure they were written for.

Industry example

The practice of publishing a commitment below the achieved figure is standard in public cloud services: providers' service level agreements state availability percentages well below what the services typically deliver, with narrow definitions and exclusions, precisely to preserve room for change. Consumers are expected to design to the published figure, which is why cloud architecture guidance consistently tells customers to build for the stated number rather than the observed one.

Internal platforms inherit the pattern without inheriting the commercial relationship. A public provider's gap is priced into a contract with credits attached; an internal platform's gap is paid in engineering time by teams with no way to charge for it, which is why the internal version needs the tiering and shared-library answers rather than only the published number.

Failure scenarios

• Forty untested fallbacks, discovered not to work during the platform's first real incident.
• Consumers quietly designing against the observed figure, so the published SLO protects nothing when it is finally needed.
• A widening gap, because nobody reports published against achieved and the platform has no incentive to narrow it.
• A fallback with worse reliability than the dependency, adding a cache with its own staleness and failure modes in front of a service that is almost always up.
• An internal service treated as never-failing, which is the most common shape of a company-wide single point of failure.
• Tiering promised and never resourced, so the higher tier exists on paper and the gap argument continues.

Trade-offs

When not to use it

When there are few consumers and they are in the same room. With three consuming teams, the gap can be negotiated directly per team and a formal published commitment adds process without information.

Also when the platform is not on a critical path. A service whose unavailability is an inconvenience rather than an outage does not need consumers building fallbacks at all, and publishing a conservative SLO there generates work for no benefit. Say that explicitly in the service's documentation, because silence will be read as a requirement.

Interview question

Q: You run an internal platform achieving 99.99% and publishing 99.9%. Forty consuming teams say the published number forces them to build fallbacks they do not need. How do you resolve it, and what do you refuse to change?

What a strong answer covers: naming what the gap buys — roughly 39 minutes a month of headroom that funds migrations, upgrades and failover tests — and who pays for it · refusing to publish the achieved figure, because the next planned migration becomes a breach · publishing commitment and achieved as two labelled numbers so the gap is visible · shipping the fallback as a platform client library, tested by the platform and exercised in its game days, replacing forty untested implementations with one · offering and resourcing a higher tier with its cost quoted · doing the chain arithmetic to check whether the gap is even observable in consumers' journeys · and the honest limit: for a service that is not on a critical path, telling consumers not to build fallbacks at all.

Quick check

Quiz: Why should a platform publish an SLO below what it achieves? — Because the gap is the headroom that pays for migrations, upgrades and failover tests, and because consumers who design against an achieved figure have their assumptions broken the first time it regresses.

Flashcard: What is the cheapest way to stop forty teams writing forty fallbacks? — Ship the fallback in the platform's client library, tested by the platform team and exercised in its own game days — one tested implementation instead of forty untested ones.