You're designing the resilience strategy for a video-streaming home page that renders: (1) 'continue watching' with playback position, (2) personalized recommendation rows, (3) trending/most-popular rows, (4) user profile avatar and account menu. Under heavy backend stress, which of these would you shed first and which would you protect longest, and how would you implement the prioritization?

## How feature shedding works Feature shedding under stress works by treating a composite page (or API response) as a set of independently callable sections rather than one monolithic must-all-succeed unit. - Each section — continue-watching, recommendations, trending, account menu — is fetched with its own timeout and its own fallback, typically behind a resilience wrapper (bulkhead plus timeout plus fallback, sometimes paired with a circuit breaker for the 'is this dependency currently healthy' decision). - The page-rendering layer then assembles whatever sections succeeded and quietly omits or substitutes the ones that didn't, rather than failing the whole page if any one section is slow. A **load-shedding policy** goes a step further: rather than waiting for each section to individually fail, the system proactively decides — based on current load, latency, or error-rate signals — to skip expensive or optional sections before they're even attempted, freeing capacity for the sections that matter most. ## Why prioritize at all This exists because a composite page has a much lower effective availability than any single dependency if every section is treated as required — the **weakest-link problem**. It also exists because, under real load spikes, not all features cost the same: an ML-driven recommendation call might be tens to hundreds of milliseconds of expensive scoring work per user, while an account-menu lookup is a cheap keyed read. When the system is under stress, continuing to spend capacity on the expensive, least-essential feature actively worsens the outage for the cheap, most-essential ones, so prioritized shedding directly protects the features users care about most by starving the ones they care about least. ## The trade-off The trade-off is **user-experience richness versus resilience and engineering complexity**. A page that always renders everything is a richer product on a good day, but every optional section is a dependency that can degrade the whole experience on a bad day unless it's explicitly isolated — and isolating N sections means N sets of timeouts, fallbacks, and monitoring to build and maintain, not one. There's also a product trade-off in the shedding order itself: recommendations drive engagement and revenue, so a business may resist ranking them as 'shed first' even though technically they're the most expensive and least essential to the immediate task — this decision has to be made jointly with product owners, not unilaterally by engineering. ## Failure modes in production 1. **The most common production failure is not defining a shedding order at all** — every section is fetched with the same priority and the same generous timeout, so under load, all sections degrade together and the whole page becomes slow rather than gracefully losing its least essential parts first. 2. **A second failure mode is a missing bulkhead** — if all sections share the same thread pool or connection pool, a slow recommendations call can exhaust the pool and starve the cheap continue-watching call even though they're logically independent: the fallback logic exists but never gets a chance to run because the request never even gets a thread. 3. **A third is shedding logic that's untested** and only exercised during real incidents, so the 'shed recommendations' code path itself has a bug that surfaces for the first time under the worst possible conditions, compounding the outage instead of mitigating it. ## Where it shows up - This is essentially how **Netflix's** home page and **Amazon's** product page are known to be built — independently fetched, independently degradable rows and widgets, each with its own fallback (e.g. Netflix's 'similar titles' falling back to a generic precomputed list), so a slowdown in one personalization service degrades one row instead of the entire page. - **Amazon engineers** have described designing the retail site so the buy box (price, availability, add-to-cart) is isolated from decorative elements like reviews and recommendations specifically so a reviews-service outage never threatens the ability to purchase. - **Load-shedding by priority** under stress is also formalized in patterns like Google's request-criticality levels in its internal RPC framework, where requests and features are tagged (e.g. critical, sheddable) so that during overload, infrastructure automatically rejects the lowest-priority traffic first to protect capacity for the highest-priority traffic — the same idea applied at the infrastructure layer rather than per page section.