Setting SLOs across a dependency chain
Reliability math across dependencies.
Serial dependencies multiply, so each backend needs a tighter SLO than the target; mitigate with redundancy, caching, and graceful degradation.
WHAT THIS TESTS This evaluates whether you understand reliability composition mathematics and can design a dependency graph that actually meets a demanding target rather than naively copying it down.
A GOOD ANSWER COVERS When a request must succeed through several dependencies in series, the overall availability is roughly the product of the individual availabilities. If each of three backends is 99.95 percent available and all are strictly required, the combined availability is about 99.95 percent cubed, near 99.85 percent, already below the 99.95 percent user-facing goal before you even count the user-facing service's own failures. So each critical dependency must be set more strictly than the target, for example pushing the hard dependencies toward 99.99 percent or better, leaving budget for the front-end service itself. The better engineering answer is to break the strict serial dependency: make backends optional or degrade gracefully, add caching so a backend outage is partly invisible, use redundancy and failover within each backend, and apply tight timeouts and limited retries so a slow dependency does not consume the whole latency or availability budget.
COMMON WRONG ANSWERS Setting each backend's SLO equal to the 99.95 percent target and expecting the whole to meet it, ignoring that serial availabilities multiply downward. Another error is unbounded retries, which can amplify load and cause cascading failure rather than improving availability.
LIKELY FOLLOW-UPS How do correlated failures break the independence assumption? How does caching change the effective dependency? How do circuit breakers and bulkheads help? How would parallel rather than serial dependencies change the math?
ONE CONCRETE EXAMPLE A checkout page needs auth, inventory, and pricing. If all three are mandatory and each is 99.95 percent, you cannot reach 99.95 percent end to end. You instead make pricing fall back to a cached value when its backend is down, serve a degraded but functional page if inventory is briefly unavailable, and tighten auth to 99.99 percent with a redundant deployment. Now a single backend hiccup degrades rather than fails the request, and the math, plus graceful degradation, lets the user-facing SLO hold despite imperfect dependencies.
Read the original → cloud.google.com
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.