Course contentsShow
← Databases & SQL
Lesson 1555 of 1,95314. High Availability and DurabilityFree lesson

Graceful Degradation Patterns

Design application logic that functions in read-only mode during a primary database outage.

In this lesson, you will learn how to design application logic that allows your system to remain operational in a "read-only" state when the primary database becomes unavailable.

The Concept of Graceful Degradation

In high-availability architecture, total system failure is often avoidable even when the primary database (the source of truth for writes) goes offline. Graceful degradation is the practice of shifting the application into a restricted mode where users can still consume existing data while preventing any state-changing operations that would lead to inconsistency or data loss.

When the database is unreachable, rather than showing an error page, the application identifies that its write capabilities are impaired and proactively blocks write-heavy paths while routing read requests to secondary replicas or cached sources.

Implementing Read-Only Mode

The pattern relies on a "Circuit Breaker" mechanism combined with a global configuration flag. When your health checks detect a primary database outage, the application toggles to READ_ONLY mode.

-- Application logic pseudo-code
IF database_write_pool.is_available() == FALSE:
    SET application_mode = 'READ_ONLY';
    DISABLE_UI_ELEMENTS(['submit_button', 'delete_action']);
    REDIRECT_TRAFFIC_TO_READ_REPLICAS();
ELSE:
    SET application_mode = 'FULL_ACCESS';

When in this state, any attempt to perform INSERT, UPDATE, or DELETE operations should be rejected at the application layer with a "Service Maintenance" message rather than reaching the database. This prevents broken connections and connection pool exhaustion.

Crucially, because your read replicas are likely still functioning (assuming your Single-Leader Replication is healthy), your users can continue searching, viewing profiles, or loading dashboards. While the system is technically "degraded" because it cannot record new activity, it remains "available" to the user, preserving the user experience until the primary node recovers or a new leader is promoted via Automated Leader Election.

This approach keeps the business running, prevents the "thundering herd" effect on a struggling primary database, and ensures that data integrity is maintained because no half-written transactions occur during the outage window.

Key Takeaway: Graceful degradation prioritizes system availability by proactively disabling write paths during outages, allowing users to safely consume cached or replicated data while the primary database recovers.