How to Gracefully Degrade Services When Server Load Spikes
This article explains various service degradation strategies—including interface and page refusal, delayed persistence, and persistent‑layer restrictions—along with management approaches and implementation points such as middleware control, NGINX+LUA page blocking, and data‑operation rules, to keep core functions running under high server pressure.
Service Degradation Overview
When server pressure surges, service degradation is applied based on current business needs and traffic, strategically lowering certain services and pages to free resources and ensure core tasks continue operating normally.
Degradation Methods
Service interface refusal: No user‑specific information is returned; the page remains accessible but add/delete actions report the server as busy. Content may be served from Varnish or CDN.
Page refusal: The page displays a message that the service is paused due to high load and redirects to a static page via Varnish or NGINX.
Delayed persistence: Page access proceeds as usual, but changes are queued or logged and applied after service recovery, with a notice that results will appear later.
Random refusal: Service interfaces randomly reject requests, prompting users to retry; this approach is rarely used because it harms user experience.
Persistent Layer Degradation
Data‑operation rules can be enforced either through cache or an asynchronous data queue:
Insert: Cache – prohibited; Async queue – allowed but duplicate entries are not permitted.
Delete: Cache – prohibited; Async queue – allowed but composite operations are not permitted.
Update: Cache – prohibited; Async queue – allowed, retaining only the final result.
Query: Cache – allowed; if not cached, query MySQL or other persistence layers; Async queue – route through cache.
Degradation Management Approaches
Intuitive management: Operations staff manually select modules to degrade. When server pressure rises, monitoring automatically notifies operators, who then set the current operating level via a configuration platform, first degrading non‑core interfaces and, if needed, pages.
Graded management: Operators choose a degradation level (1–10) without needing business details. The system automatically determines which applications should reduce functionality based on the selected level.
Degradation Injection Points
Degradation can be embedded at several layers:
Message middleware: All API calls can be controlled via messaging middleware.
Front‑end pages: Specific URLs can be blocked using NGINX with Lua scripts.
Underlying data layer: All insert, delete, and update actions are rejected, allowing only queries.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
ITFLY8 Architecture Home
ITFLY8 Architecture Home - focused on architecture knowledge sharing and exchange, covering project management and product design. Includes large-scale distributed website architecture (high performance, high availability, caching, message queues...), design patterns, architecture patterns, big data, project management (SCRUM, PMP, Prince2), product design, and more.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
