Microservice Resilience: Rate Limiting, Circuit Breaker, Degradation & Debounce

Why microservices must implement fault tolerance

After solving distributed data inconsistency, the biggest hidden risk in microservice architecture is cascading failures. In a monolith failures are isolated; in microservices downstream latency or errors quickly propagate upstream, causing request pile‑up, thread exhaustion, widespread timeouts, CPU spikes, and a service avalanche.

Four core fault‑tolerance mechanisms are required: rate limiting, circuit breaking, degradation, and debounce.

Service avalanche definition

Simple definition: a downstream service failure blocks all upstream calls, leading to request accumulation and a complete chain collapse.

Full chain example: service crash or slow query → massive upstream timeouts → thread‑pool exhaustion → new requests cannot be processed → all dependent business logic stalls → site‑wide outage.

Goal of the four mechanisms: cut off fault propagation, preserve core functionality, discard non‑essential parts, keep the system alive.

Rate limiting (entry‑level protection)

Core principle: limit the number of requests per unit time; excess requests are rejected to prevent the service from being overwhelmed.

Typical scenarios: flash‑sale spikes, scheduled purchases, malicious API scraping, high‑frequency repeated calls.

Common algorithms:

Counter limiting: simple count per second, suitable for basic cases.

Sliding window limiting: improves precision for burst traffic.

Token bucket limiting: tokens are generated at a steady rate; requests consume tokens, ideal for bursty traffic.

Leaky bucket limiting: requests exit at a constant rate, strictly controlling processing speed for smooth traffic.

Implementation layers: gateway‑level limiting (global interception) combined with interface‑level limiting (fine‑grained protection) provides a double safety net.

Circuit breaking (core avalanche prevention)

Core principle: when downstream services frequently error or timeout, the call chain is broken, stopping further requests to the faulty service.

This avoids useless waiting, thread pile‑up, and gives the failing service time to recover.

Circuit breaker states:

Closed: service operates normally, calls proceed.

Open: failure rate exceeds threshold; calls are rejected and fallback data is returned.

Half‑Open: after a cooldown, a limited number of test requests probe the service; if successful the circuit closes, otherwise it stays open.

Applicable scenarios: unstable downstream services, frequent timeouts, soaring error rates, or network jitter.

Degradation (protect core business under overload)

Core principle: during traffic spikes or high load, non‑essential functions are proactively disabled to free resources for critical operations.

Difference from circuit breaking: circuit breaking reacts to failures; degradation is an active strategy.

Degradation types:

Page degradation: hide homepage carousel, recommendations, hot lists, etc.

Interface degradation: disable logging, points push, message notifications, and other secondary APIs.

Data degradation: skip real‑time queries, return cached or default data.

Core idea: prefer fewer functions over a complete service collapse.

Debounce (eliminate redundant requests)

Core principle: within a short time window, identical requests are processed only once; subsequent duplicates are blocked.

Addresses issues caused by accidental multiple clicks, network retries, or front‑end retry loops.

Common scenarios: repeated button clicks, duplicate order submissions, repeated payment attempts, form resubmissions.

Implementation approach: combine front‑end debounce filtering with back‑end Redis distributed locks or unique‑ID deduplication for double‑layer protection.

Comparison of the four mechanisms

Rate limiting: prevents excessive traffic, blocks over‑quota requests, protects the service entry point.

Circuit breaking: stops downstream failures, cuts fault chains, prevents avalanche spread.

Degradation: proactively drops non‑core load during overload, preserving core business.

Debounce: prevents duplicate requests, avoids invalid operations caused by user or network errors.

Production‑level protection combo

Gateway global rate limiting: intercept massive or malicious traffic at the first line of defense.

Service circuit breaking with fallback: automatically cut off failing downstream calls.

Peak‑time proactive degradation: disable secondary features to safeguard transactions and order processing.

Global interface debounce: block duplicate submissions, preventing dirty data.