API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) · Lektion

Bulkheads & Rate Limiting für Resilienz

Isolieren Sie Fehler und schützen Sie nachgelagerte Services mit Bulkhead-Isolation und dem RequestRateLimiter-Filter des Gateways.

Bulkheads & Rate Limiting für Resilienz ist eine kostenlose API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)-Kurs umfasst insgesamt 4 Lektionen.

Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.

Containing the Blast Radius

Circuit breakers stop calls to a broken service, but a flood of traffic to one route can still starve others. Bulkheads and rate limiting keep one busy route from sinking the whole gateway.

The Bulkhead Pattern

Named after a ship's watertight compartments, a bulkhead caps how many concurrent calls a route may have. If one service slows down, only its compartment fills, sparing the rest.

Resilience4j Bulkhead Config

Resilience4j offers a bulkhead that limits concurrent calls per instance.

resilience4j:
  bulkhead:
    instances:
      orders:
        maxConcurrentCalls: 20

Why Rate Limiting Differs

A bulkhead caps concurrency; a rate limiter caps requests over time. Together they protect both fast bursts and sustained load.

The RequestRateLimiter Filter

Spring Cloud Gateway ships a RequestRateLimiter filter backed by a Redis token bucket. It rejects excess requests with HTTP 429.

filters:
  - name: RequestRateLimiter
    args:
      redis-rate-limiter.replenishRate: 10
      redis-rate-limiter.burstCapacity: 20

Replenish Rate and Burst

replenishRate is the steady tokens per second; burstCapacity is the most that can be spent in a spike. Burst should be greater than or equal to replenish.

Choosing a KeyResolver

A KeyResolver decides what to limit by, such as user, API key, or IP. Here we limit per user from a header.

@Bean
KeyResolver userKeyResolver() {
    return exchange -> Mono.just(
        exchange.getRequest().getHeaders()
            .getFirst("X-User-Id"));
}

Redis Backing Store

The limiter needs Redis so counts are shared across gateway instances. Add the reactive Redis starter.

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-data-redis-reactive</artifactId>
</dependency>

Combining Patterns

Stack resilience filters on a route: circuit breaker first, then rate limiter, so traffic is shaped before reaching a possibly fragile backend.

filters:
  - name: CircuitBreaker
    args:
      name: ordersCB
      fallbackUri: forward:/fallback/orders
  - name: RequestRateLimiter
    args:
      redis-rate-limiter.replenishRate: 10
      redis-rate-limiter.burstCapacity: 20

Graceful Rejection

When the limit is exceeded the client gets 429. You can customize the status, but always return a clear, retryable response so clients can back off.

args:
  redis-rate-limiter.replenishRate: 5
  statusCode: TOO_MANY_REQUESTS

Observing the Limits

Watch metrics for 429 counts and bulkhead rejections. Tune the numbers based on real downstream capacity, not guesses.

Quick Check

What is the core difference between a bulkhead and a rate limiter?

Recap

You added two more resilience tools:

Bulkheads cap concurrent calls per route
RequestRateLimiter uses a Redis token bucket
replenishRate and burstCapacity shape traffic
A KeyResolver defines the limiting key

Combined with circuit breakers, retries, and fallbacks, your gateway degrades gracefully under stress.

Häufig gestellte Fragen

Ist die Lektion „Bulkheads & Rate Limiting für Resilienz“ kostenlos?

Ja — der vollständige Text von „Bulkheads & Rate Limiting für Resilienz“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Bulkheads & Rate Limiting für Resilienz“?

Isolieren Sie Fehler und schützen Sie nachgelagerte Services mit Bulkhead-Isolation und dem RequestRateLimiter-Filter des Gateways. Du übst API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) zu starten?

Keine Vorkenntnisse erforderlich. API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Bulkheads & Rate Limiting für Resilienz“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)-Lektion Code schreiben und ausführen?

Ja. Jede API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

← Zurück zu API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)