A product team commits to 99.95% availability. Their service depends on your platform's ingress, config service and secret manager. What do you tell them?
Show the full answer Hide the answer
What the interviewer is testing
Whether you can do dependency arithmetic and whether the platform publishes numbers that make the conversation possible.
The arithmetic
Serial hard dependencies multiply. If the three platform components offer 99.9%, 99.95% and 99.9%, the ceiling before the service's own code runs is:
0.999 × 0.9995 × 0.999 ≈ 99.79%
That is about 18 hours of unavailability a year, against a commitment of 4.4 hours. The target is unreachable, and no effort inside the product service changes that.
The options
Reduce hard dependencies in the request path. This is nearly always the answer. The config service and secret manager should not be called per request — cache locally with a long fallback, so a control-plane outage does not fail the data plane. That converts two hard dependencies into soft ones and the arithmetic becomes tractable.
Raise the platform's objectives, which means investment on the platform side and needs justification across all consumers, not one.
Lower the product target to something the architecture supports.
Add redundancy where the failures are genuinely independent — which for a shared platform component they usually are not.
The general principle
Never let a control plane sit in the data plane's request path. Control planes are more complex and less reliable than data planes, in every system including every cloud provider's. A service that fetches a secret or a feature flag per request has quietly adopted the availability of the management system.
What a strong answer adds
Distinguishing hard from soft dependencies explicitly in the design: a hard dependency's failure fails the request; a soft one degrades it. Most dependencies can be made soft with a cache, a default or a fallback, and doing that deliberately is what makes ambitious availability targets achievable.
And noting that publishing platform SLOs is what makes this conversation happen at design time rather than at the first incident review.
Common weak answers
Accepting the commitment and hoping. Telling the team to add retries, which does not help when the dependency is down rather than flaky.