A streaming service's homepage assembles rows from a dozen personalisation services. One returns 4-second latency instead of 40 ms. What happens, and what should have been designed?

What the interviewer is testing

Whether you can trace a slow dependency through to user impact and reach fallbacks rather than retries.

What happens without design

The homepage waits. If rows are fetched in parallel and the page waits for all of them, the page's latency is the slowest of twelve, so a single degraded service makes the whole homepage take four seconds.

Worse, at the caller: each pending request holds a thread or connection for 100 times longer than normal. By Little's Law, occupancy rises proportionally and the pool exhausts within seconds — at which point the homepage service cannot serve any request, including ones that never touch the slow personalisation service.

A single degraded optional feature has become a total outage.

What should have been designed

A per-row deadline far below the page budget. If the page must render in 800 ms, no individual row gets more than a few hundred milliseconds. When it expires, that row is abandoned.

A fallback per row. A personalised row that fails is replaced by a static or cached one — popular titles, recently added, a genre list. The user sees a slightly less relevant homepage rather than an error. This is the design that makes the row a soft dependency.

Bulkheads, so each personalisation service has its own connection pool and cannot exhaust the shared one.

Render partially. The page returns with the rows that arrived. Late rows either fill in client-side or do not appear.

What a strong answer adds

The availability arithmetic that motivates it: twelve serial hard dependencies at 99.9% each gives a ceiling of about 98.8%, before the homepage service's own reliability. Converting them to soft dependencies removes them from the multiplication entirely, which is the only way an ambitious availability target is reachable with a fan-out this wide.

And the note that this fallback discipline is the precondition for chaos engineering, not a consequence of it — Netflix can terminate instances in production because a failed row degrades rather than fails.

Common weak answers

Adding retries, which multiplies load on a service that is already slow. Caching the personalisation result without addressing what happens on a cold cache.