1. Overload and cascading failures

The interviewer says one backend got slow and the whole site fell over, and asks why and what you would do about it. That is overload: a service is sent more work than it can finish before its callers give up. A cascading failure is overload that spreads, because slow work keeps holding capacity in every service that waits on it. In a photo-sharing app, a slow database of photo metadata can take down the upload API even though the database never goes down.

The principle is short. A server has a fixed number of workers, so work it cannot start waits in a queue, and a request that waits too long has failed, because the user has already given up. The fix is to refuse or shrink work early, in an order chosen in advance, so the accepted work can still finish.

Reach for this when servers sit at full load while users report timeouts, or a restart is followed by a second outage. Skip it for a service with spare capacity and no slow dependency, where a timeout and an alert are enough.

This is often a full question in site reliability engineering (SRE) loops and a minute or two of a general design round. Mid-level candidates name a timeout, a bounded retry, and load shedding. Senior candidates also explain why a fully busy fleet can have zero goodput (the work that finishes before its caller gives up), choose what to shed and what to degrade, and plan the recovery. The chapters follow the order an interviewer usually asks about them.