How would you design a service so that losing an entire availability zone, or a key dependency, does not take the whole product down?

What the interviewer is looking for

• This question tests capacity & resilience design. Uses load testing, forecasting, redundancy, graceful degradation and failure testing to make systems survive spikes and outages.
• Strong answers: Redundancy across zones, timeouts, retries with backoff, circuit breakers, graceful degradation, caching, and regular failure testing.
• Likely follow-up: How would you test that this actually works without hurting real users?

Another way it may be asked: Imagine one data center or a third-party service goes offline. How should your system be built so customers barely notice?

A structure to follow: Requirements, sketch, deep-dive, trade-offs

1. Step 1

   Requirements

   Ask who uses it, what it must do, and which qualities matter most: speed, reliability, cost, consistency.

2. Step 2

   Sketch

   Draw the main parts and the path one request takes through them before adding detail.

3. Step 3

   Deep-dive

   Pick the riskiest part (storage, queueing, failure handling) and go deeper there.

4. Step 4

   Trade-offs

   Name what you gave up for each choice, and what you would do first if it needed to grow.

This is guidance on shape, not a script. Use your own real experience and facts; never invent details to fill a gap. See the STAR guide and answer frameworks.

Common slips

• Naming tools before establishing requirements.
• Drawing every box at the same depth instead of going deep where it matters.
• Presenting one design as the only answer, with no trade-offs.

How to practise it

Time yourself: two minutes on requirements, five on the sketch, five on one deep-dive, two on trade-offs.

Related questions

• A big marketing launch is expected to triple traffic in six weeks. How would you prepare the system and prove it is ready?
• What is the difference between a service level indicator, a service level objective and a service level agreement, and why would a team care about the difference?
• A Linux server is suddenly very slow. What are the first things you would check, and what would each one tell you?
• You are on call, and at two in the morning you get paged that the checkout page is returning errors. What do you do in the first ten minutes?
• How do you decide what deserves to page a human at night versus what can wait for a ticket in the morning?

Browse all questions