Design for Resilience

"Design for resilience" is the system design prompt that Netflix probes harder than almost any company. It shows up phrased as "design a fault-tolerant streaming service," or "handle the traffic spike when a show releases," or simply as the part of any other design where the interviewer keeps asking what happens when something breaks. The other Netflix designs reach a working architecture and then turn here. This lesson makes resilience the whole prompt rather than the last deep dive. It is the sibling of the streaming design, and it goes further on failure than that lesson had room to.

Anchor on the operating reality first. At Netflix scale something is always partially broken. Across hundreds of thousands of instances and dozens of microservices in the path of a single play request, at any given moment an instance is slow, a dependency is timing out, or a region is degraded. On top of that steady background of small failures, demand is spiky. A hit title drops at the same evening hour worldwide, or a live event kicks off, and traffic to some services jumps many times over in minutes. The requirement that falls out of those two facts is blunt. One failing piece must never cascade into "Netflix is down." Failure is the normal case here. Netflix designs for it as an everyday event the system is built to absorb.

The Netflix angle

This prompt lands differently at Netflix for three reasons. Resilience is the round, so the interviewer will push on failure long after a generic interview would have moved on to the next feature. The person across the table may have built the very tools you are about to name, since Netflix invented or popularized much of this vocabulary: Hystrix circuit breakers, the Simian Army, regional evacuation. And the format is conversational and often has no diagramming tool, so practice narrating a failure path in words: what trips, what falls back, what the viewer sees. Reach a baseline quickly.