Graceful degradation in system design

Graceful degradation means the system keeps the most important user flow working even when some part of the system is slow, unavailable, or failing.

Modern systems depend on many things: databases, caches, search services, recommendation systems, payment providers, image services, analytics pipelines, third-party APIs, and more.

If every dependency failure causes the entire product to fail, the system is brittle.

Suppose an ecommerce product page depends on these features:

• product details
• price
• inventory status
• recommendations
• reviews
• recently viewed items
• analytics tracking

These are not equally important. If analytics or recommendations are down, the user should probably still be able to view the product and checkout.

Without graceful degradation, the product page may fail because one optional feature failed.

Bad:
Product Page
    needs Product API
    needs Price API
    needs Recommendation API

Recommendation API times out
    ↓
Entire Product Page returns 500

A better design treats recommendations as optional.

Better:
Product API succeeds
Price API succeeds
Recommendation API times out
    ↓
Show product
Show price
Hide recommendations
Still allow checkout

This is a simplified example showing the idea. If recommendations fail, the page still returns with an empty recommendation list.

import java.util.List;

public class ProductPageService {
    private final ProductClient productClient;
    private final RecommendationClient recommendationClient;

    public ProductPageService(
            ProductClient productClient,
            RecommendationClient recommendationClient
    ) {
        this.productClient = productClient;
        this.recommendationClient = recommendationClient;
    }

    public ProductPage getProductPage(String productId) {
        Product product = productClient.getProduct(productId);

        List<Product> recommendations;

        try {
            recommendations =
                    recommendationClient.getRecommendations(productId);
        } catch (RuntimeException ex) {
            recommendations = List.of();
        }

        return new ProductPage(product, recommendations);
    }

    record Product(String id, String name) {}

    record ProductPage(
            Product product,
            List<Product> recommendations
    ) {}

    interface ProductClient {
        Product getProduct(String productId);
    }

    interface RecommendationClient {
        List<Product> getRecommendations(String productId);
    }
}

In a real system, you would usually log the failure and emit a metric so the degraded mode is visible to operators.

Analytics is useful, but it usually should not block the customer from completing an order.

Bad:
User clicks checkout
    ↓
Write order
    ↓
Send analytics event synchronously
    ↓
Analytics system is slow
    ↓
Checkout becomes slow or fails

Better:
User clicks checkout
    ↓
Write order
    ↓
Publish analytics event asynchronously
    ↓
Return success to user

Graceful degradation should be intentional. For each dependency, ask:

• Is this dependency required for the core user flow?
• What happens if it is slow?
• What happens if it is unavailable?
• Can we use cached data?
• Can we return partial results?
• Can we hide this feature temporarily?
• Can we queue the work for later?
• How will we know we are in degraded mode?

These ideas are related, but they are not the same.

Example: a timeout or circuit breaker may fail fast. The fallback behavior after that failure is graceful degradation.

Degraded mode should not be invisible. You want to know when users are getting a reduced experience.