Error Handling and Resilience at the System Level

The plain-language idea

A frontend system design answer that only covers the happy path is an incomplete answer. Interviewers listen for whether a candidate treats failure as a first-class part of the design, not an afterthought bolted on at the end. Three patterns cover most of what a frontend system needs to say here:

• Retry with exponential backoff. A failed request to a flaky dependency is often worth retrying — but retrying immediately, repeatedly, at full speed just adds load to something that's already struggling. Exponential backoff waits longer between each successive retry (1s, 2s, 4s, 8s...), giving the dependency room to recover instead of hammering it.
• Graceful degradation. When a piece of the UI fails, the rest of the app should keep working. This platform's React track covers error boundaries in depth as the concrete mechanism — a boundary catches a rendering error in one part of the tree and shows a fallback there, without taking down the entire page. In a system design answer, the point isn't re-explaining how they work, it's where you'd place them: around each independently-failable unit (a widget, a panel), not one boundary wrapping the whole app.
• A circuit breaker, simplified for the client. If a specific endpoint has failed repeatedly in a short window, stop calling it for a cooldown period instead of retrying it on every subsequent user action. This protects both the struggling backend and the user's experience — no point showing five spinners in a row for a call that's going to fail the same way each time.

See it in a real thing: a dashboard widget hitting a flaky analytics endpoint

One widget on a dashboard fetches from an analytics service that's currently degraded. A naive implementation retries on every render and every user interaction, throws an unhandled error that crashes the whole page, and gives the user zero explanation. A resilient design: wrap the widget in an error boundary so a failure there shows "Analytics unavailable" in that one card while the rest of the dashboard keeps rendering normally; retry the fetch with exponential backoff a bounded number of times; and if failures keep happening past a threshold, trip a simple client-side circuit breaker — stop issuing new requests to that endpoint for, say, 60 seconds, and show a static "temporarily unavailable" state instead of silently retrying forever.

What people usually miss

Watch out

• Retrying without backoff can make an already-struggling dependency worse, not better — a flood of immediate retries from many clients at once is a real, well-known way outages get prolonged instead of recovered from.
• One error boundary around the entire app is barely better than no error boundary. The design decision that actually matters is placement — scoping boundaries around independently-failable units so one broken widget doesn't take the whole page down with it.
• A circuit breaker isn't about giving up — it's about failing fast and predictably instead of failing slowly and repeatedly. Once a dependency is known to be down, stopping requests for a cooldown period is a better user experience than five consecutive timeouts.
• Resilience patterns are rarely the headline of a prompt, but their absence is a real gap an interviewer will notice. A design that only covers the happy path reads as incomplete even if everything else about it is strong.

Why this matters in interviews

Almost any "design X" prompt eventually gets the follow-up "what happens if that API call fails?" — naming retry-with-backoff, scoped graceful degradation, and a simple circuit-breaker cooldown together is the concrete, complete answer.