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

> Split the critical path (browse, cart, checkout) from the nice-to-haves, put those behind feature flags with short timeouts, and rehearse the kill-switch.

- Asked: 2026-05-28
- Answered: 2026-05-31
- Asked by: Hakan
- Tags: dayaniklilik, mimari, olcekleme
- Source: https://www.muhammetsafak.com.tr/en/just-ask/graceful-degradation-isolating-non-critical-services-under-load/
- Language: en-US
- Author: Muhammet Şafak

---
**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?


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.

## Related Reading

- [How do I set up a Circuit Breaker for a flaky third-party API dependency?](https://www.muhammetsafak.com.tr/en/just-ask/circuit-breaker-for-flaky-third-party-apis/) — Just Ask
- [Multi-tenant SaaS database isolation: separate DB, schema, or tenant_id?](https://www.muhammetsafak.com.tr/en/just-ask/multi-tenant-saas-database-isolation-for-10k-tenants/) — Just Ask
- [When moving local files to S3, is EFS a good interim step?](https://www.muhammetsafak.com.tr/en/just-ask/moving-local-files-to-s3-is-efs-a-good-interim-step/) — Just Ask