Graceful degradation: how do I isolate non-critical services under load?
Question
On Black Friday the system was overloaded and the DB CPU hit 98%. I want to apply graceful degradation to stop the site from going down entirely. While users can still add to cart and check out, how do I dynamically turn off non-critical services like "Recommended Products", "Similar Products" and "Reviews" or route them to mock data?
Answer
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.
Short answer
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. I covered how a single slow dependency drags the whole system down in the circuit breaker answer; the issue here is building that isolation at the product level.
Why
-
A crisis is not a decision-making moment. You decide which component is sacrificeable while calm, not at 98% CPU.
-
A slow nice-to-have drags the critical path down. If the recommendations service waits 3 seconds, checkout is the one paying for that wait.
-
An untested kill-switch is a guess. You have no evidence that a button first pressed during a crisis will work.
What to do
-
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 behind an independently disable-able feature flag.
-
Put a short timeout + static fallback on every nice-to-have service. If recommendations don’t answer in 200ms, return empty or show a cached list.
-
Disable instantly with a kill-switch. A single flag should turn off all nice-to-have components live, with no deploy.
-
Protect the DB with load shedding. Return
503early for non-critical endpoints; don’t let those requests reach the DB at all. -
Isolate the core path with a bulkhead. Give critical and non-critical traffic separate connection pools / workers.
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.
Comments
Sign in with your GitHub account to join the discussion. Comments are stored in GitHub Discussions.