Graceful degradation is an architectural principle that designs systems to preserve core functionality under partial failure or high load while sacrificing nonessential features. It increases fault tolerance and enables controlled degraded operating modes instead of total outages. Applicable across user interfaces, services, and distributed platforms.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What you need to understand to reason about a domain.
Graceful degradation is an architectural principle that keeps a system usable under partial failure or overload by reducing or disabling less critical functions.
The idea sits within fault tolerance and resilience: systems should remain useful when components fail, resources run short, or traffic spikes instead of collapsing completely. In web and service architecture, intentionally stepping features down became important; HTML illustrates forward compatibility, and SRE treats degraded responses as a response to overload and cascading failures.
Think of a system with a core function, a comfort layer, and an emergency mode. When load rises or a dependency fails, optional parts are reduced first: images load later, results become coarser, search uses a smaller candidate set, or a service returns simplified data. A priority order determines what stays and what gets sacrificed.
Critical tasks take precedence over convenience and extra features.
Simplified paths or substitute data keep the workflow usable when the normal path fails.
Additional work is deliberately limited or rejected so core functions remain available.
The system switches in a controlled way between clearly defined operating modes.
A robust baseline prevents partial faults from turning immediately into full unavailability.
The principle matters when a service must keep the most important tasks working during failures or traffic spikes, for example in UIs, search, or distributed services. It requires clear priorities, tested fallbacks, and monitoring. The trade-off is intentionally lower quality or reduced feature depth; without root-cause fixes, degradation can only mask problems.
Where this building block is located in the topic model.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.