Graceful degradation: how do I isolate non-critical services under load?

Short answer: graceful degradation isn’t a coding technique, it’s a decide-in-advance discipline. Decide what’s critical and what’s nice-to-have before Black Friday arrives; the rest is just flipping flags.

The real problem is this: if you start thinking about which service to turn off at 98% CPU, you’ve already lost. The core path (browse a product, add to cart, check out) must always stay up; the “nice-to-haves” must be sacrificeable.

1. Separate critical from nice-to-have and label them. Browse, cart, checkout are critical. Recommended products, similar products, reviews are nice-to-have. Put each nice-to-have component behind an independently disable-able feature flag. The decision has to be made today, not in the middle of the crisis.
2. Put a short timeout + static fallback on every nice-to-have service. If the recommendations service doesn’t answer in 200ms, don’t wait — return empty or show a cached/mock list. That way a slow recommendations service can never drag checkout down.
3. Disable instantly with a kill-switch. Under load, a single flag should let you turn off all the nice-to-have components or route them to mock data. It must be a switch that takes effect live with no deploy.
4. Protect the DB with load shedding. Return 503 early for non-critical endpoints; don’t let those requests reach the DB at all. The way to save the database before a few extra seconds of load piles on is to reject demand at the door.
5. Isolate the core path with a bulkhead. Give critical and non-critical traffic separate connection pools / workers. That way a spike in nice-to-have traffic can’t starve checkout’s connection pool.

Bottom line: I’d build the flags and fallbacks in advance and rehearse the “Black Friday switches” before the day comes. An untested kill-switch is a guess that it’ll work when the crisis hits. You want to run a predefined scenario, not improvise at 98% CPU.