Netflix System Design
Failure Scenarios
Interview pattern:Interviewers ask “what happens if X is down?” for every component you draw. Have a rehearsed answer for each: user impact, detection method, mitigation, and whether you fail open or closed.
Failure Matrix
Click any row to expand: user impact, detection, mitigation, fallback, and what to say.
Fail Open vs Fail Closed — Quick Reference
Memorize this table. Interviewers test it directly.
| Component / Scenario | Decision | Reason |
|---|---|---|
| Playback (service down) | FAIL OPEN | Degraded stream > no stream |
| Billing (during active session) | FAIL OPEN | Cached entitlement is sufficient for short TTL |
| DRM License | FAIL CLOSED | Studio contract — legally required |
| Concurrency limit (race condition) | FAIL CLOSED | Prevent account limit bypass |
| Recommendations | FAIL OPEN | Three-tier fallback always exists |
| Search | FAIL OPEN | Cached results / trending fallback |
| Watch History write | FAIL OPEN | Stale resume is tolerable |
| New user entitlement (no cache) | FAIL CLOSED | Unknown user = deny by default |
| Kafka event ingestion | FAIL OPEN | Analytics must not block playback |
📋 Say This In Interview
The guiding principle: fail open for user experience, fail closed for security and legal obligations. Playback fails open because a degraded stream beats a black screen. DRM fails closed because studio contracts require it. Billing fails open for active users with cached entitlement — fail closed only for new or unknown users. Recommendations always have a three-tier fallback. Analytics and watch history writes are async and never block playback.
Last reviewed June 2026 · By Prasoon ParasharNumbers are interview assumptions, not real Netflix internal figures.
Was this tab useful for interview prep?