Your service depends on five other services, each with a 99.9% availability SLO. You are asked to offer a 99.99% SLO. How do you respond?

What the interviewer wants to hear

• Serial dependencies multiply: about 99.5% if all are critical
• You cannot be more reliable than hard dependencies without design changes
• Options: redundancy, caching, async processing, graceful degradation
• Measure the real dependency impact and question whether 99.99% is needed
• Cost and engineering effort grow sharply with each nine

Model answer

If all five are hard dependencies on the critical path, their availability multiplies: 0.999 to the power 5 is about 99.5%, before counting our own failures. So promising 99.99% would be impossible without changing the design. I would first ask whether users really need 99.99%, because each extra nine costs much more engineering and money. If it is needed, I would remove dependencies from the critical path: cache responses, serve stale data, move work to asynchronous queues, degrade gracefully by hiding non-essential features, and add redundancy such as calling replicas in different regions. I would also check real measured availability of each dependency, since it may be better than its SLO, and agree an SLO that matches what the architecture can actually deliver.

More hard Site Reliability Engineer questions

• What causes cascading failures in distributed systems, and how do you design to prevent them?
• Your service fans out to many backends and its p99 latency is much worse than the backends. How would you reduce tail latency?
• How do you make deployments on Kubernetes reliable with zero downtime and safe rollback?
• How would you introduce chaos engineering to an organisation that has never done it?
• Design a strategy so that a customer-facing service survives the loss of an entire cloud region. What trade-offs do you consider?
• Your observability bill (metrics, logs and traces) has tripled in a year and leadership wants it cut by 40% without losing the ability to debug incidents. How do you do it?
• After a brief dependency outage, your service stays overloaded long after the dependency recovered. How do you get out of this state, and how do you design to avoid it?
• Many large outages are caused by configuration changes rather than code. How would you design a safe configuration change process for a large fleet?
• You lead a new SRE team in a company with frequent outages. How do you decide what to work on first, and how do you show the work is paying off?