API Rate Limiting & Scalability Patterns · Pelajaran

Menangani Pelampauan Batas Laju

Jelajahi praktik terbaik untuk menanggapi pelanggaran batas laju, termasuk kode status HTTP 429 dan header retry-after.

Menangani Pelampauan Batas Laju adalah pelajaran API Rate Limiting & Scalability Patterns gratis di CoddyKit. Ini adalah pelajaran 3 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar API Rate Limiting & Scalability Patterns, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus API Rate Limiting & Scalability Patterns mencakup 4 pelajaran total.

Bagian dari pelajaran ini belum diterjemahkan dan ditampilkan dalam bahasa Inggris.

What Happens When You Hit a Limit?

Imagine an API as a busy service counter. If too many people (requests) try to get help at once, the counter gets overwhelmed.

Rate limiting helps manage this traffic. But what happens when you, as an API client, send too many requests and hit that limit?

The API needs a way to tell you to slow down, and you need to know how to respond gracefully.

HTTP 429: Too Many Requests

The standard way for an API to signal that you've exceeded a rate limit is by returning an HTTP 429 Too Many Requests status code.

It's a clear, machine-readable signal.
It tells your application, "Hey, you've sent too many requests in a given time period."
It's crucial for both server stability and client guidance.

Guiding Retries with Retry-After

Just saying "429 Too Many Requests" isn't enough. Clients need to know when they can try again. That's where the Retry-After HTTP header comes in.

This header tells the client how long to wait before making another request. It can be:

A number of seconds (e.g., Retry-After: 60 for 60 seconds).
A specific date and time (e.g., Retry-After: Tue, 01 Mar 2024 10:00:00 GMT).

Server: Sending a 429 Response

As an API provider, you need to implement logic to detect rate limit violations and respond correctly. Here's a conceptual Java example of how a server might simulate sending a 429 response with a Retry-After header.

public class Main {
  public static void main(String[] args) {
    int requestsMade = 5;
    int limit = 3;
    
    System.out.println("Simulating a server response...");
    
    if (requestsMade > limit) {
      System.out.println("HTTP/1.1 429 Too Many Requests");
      System.out.println("Content-Type: text/plain");
      System.out.println("Retry-After: 60"); // Wait 60 seconds
      System.out.println("\nBody: You have exceeded your rate limit.");
    } else {
      System.out.println("HTTP/1.1 200 OK");
      System.out.println("Content-Type: text/plain");
      System.out.println("\nBody: Request successful!");
    }
  }
}

Client: Understanding When to Retry

When your client application receives a 429 response, it should parse the Retry-After header. This is critical for smart retrying.

If the value is a number, convert it to milliseconds and wait.
If it's a date, calculate the difference to determine the wait time.

Ignoring this header can lead to continued rate limit violations or even getting blocked.

Smart Retries: Exponential Backoff

What if the API doesn't send a Retry-After header, or you need a general strategy? Exponential backoff is a common and effective pattern.

Instead of retrying immediately, you wait for an increasingly longer period after each failed attempt. This reduces the load on the server and gives it time to recover.

Start with a small initial delay (e.g., 1 second).
Double the delay after each consecutive failure (1s, 2s, 4s, 8s...).
Set a maximum number of retries or a maximum delay.

Client: Exponential Backoff Example

Here's how you might implement a simple exponential backoff strategy in Java. This example simulates an API call that initially fails, then succeeds after a delay.

public class Main {
  public static void main(String[] args) {
    int maxRetries = 3;
    long delay = 1000; // Start with 1 second (1000 ms)
    boolean apiCallSuccessful = false;

    for (int i = 0; i < maxRetries; i++) {
      System.out.println("Attempt " + (i + 1) + ": Making API call...");
      // Simulate API call failure on first attempt, success after
      boolean rateLimited = (i == 0); 

      if (rateLimited) {
        System.out.println("API call failed (429). Retrying in " + (delay / 1000) + "s...");
        try {
          Thread.sleep(delay);
        } catch (InterruptedException e) {
          Thread.currentThread().interrupt();
          System.out.println("Retry interrupted.");
          break;
        }
        delay *= 2; // Double the delay for the next attempt
      } else {
        System.out.println("API call successful!");
        apiCallSuccessful = true;
        break; // Exit loop on success
      }
    }
    if (!apiCallSuccessful) {
      System.out.println("Max retries reached. Giving up.");
    }
  }
}

Preventing Thundering Herd with Jitter

When many clients use exponential backoff, they might all retry at roughly the same time, causing a "thundering herd" problem.

To avoid this, add a small, random amount of jitter (randomness) to your calculated delay. This spreads out the retries, further reducing the server load.

import java.util.Random;

public class Main {
  public static void main(String[] args) {
    int maxRetries = 3;
    long baseDelay = 1000; // Start with 1 second (1000 ms)
    Random random = new Random();
    boolean apiCallSuccessful = false;

    for (int i = 0; i < maxRetries; i++) {
      System.out.println("Attempt " + (i + 1) + ": Making API call...");
      boolean rateLimited = (i == 0); // Simulate 429 on first try

      if (rateLimited) {
        long currentExpDelay = baseDelay * (long) Math.pow(2, i); // Exponential part
        long jitter = random.nextInt((int) (currentExpDelay / 2) + 1); // Add up to 50% random delay
        long totalDelay = currentExpDelay + jitter;

        System.out.println("API call failed (429). Retrying in " + (totalDelay / 1000) + "s (base: " + (currentExpDelay/1000) + "s, jitter: " + (jitter/1000) + "s)...");
        try {
          Thread.sleep(totalDelay);
        } catch (InterruptedException e) {
          Thread.currentThread().interrupt();
          System.out.println("Retry interrupted.");
          break;
        }
      } else {
        System.out.println("API call successful!");
        apiCallSuccessful = true;
        break;
      }
    }
    if (!apiCallSuccessful) {
      System.out.println("Max retries reached. Giving up.");
    }
  }
}

Graceful Degradation: When Retries Aren't Enough

Sometimes, even with smart retries, an API might remain unavailable or your application can't afford to wait. This is where graceful degradation comes in.

Instead of showing a full error, your application can provide reduced functionality or cached data to the user.

Display older, cached data instead of real-time.
Temporarily disable non-critical features.
Prompt the user to try again later, explaining the situation.

Rate Limit Response Check

You've learned how APIs signal rate limit exceedance and how clients should respond. Let's check your understanding.

Summary: Handling Rate Limits

In this lesson, we explored how to effectively handle rate limit exceedance from both the server and client perspectives.

APIs use HTTP 429 Too Many Requests and the Retry-After header to communicate limits.
Clients should parse Retry-After or use exponential backoff.
Adding jitter prevents the "thundering herd" problem.
Graceful degradation ensures a better user experience when retries aren't viable.

Mastering these techniques leads to more robust and resilient API integrations.

Pertanyaan yang Sering Diajukan

Apakah pelajaran “Menangani Pelampauan Batas Laju” gratis?

Ya — teks lengkap “Menangani Pelampauan Batas Laju” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus API Rate Limiting & Scalability Patterns, upgrade ke CoddyKit PRO. Kursus API Rate Limiting & Scalability Patterns mencakup 4 pelajaran total.

Apa yang akan aku pelajari di “Menangani Pelampauan Batas Laju”?

Jelajahi praktik terbaik untuk menanggapi pelanggaran batas laju, termasuk kode status HTTP 429 dan header retry-after. Kamu berlatih API Rate Limiting & Scalability Patterns dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.

Apakah aku perlu pengalaman untuk memulai API Rate Limiting & Scalability Patterns?

Tidak diperlukan pengalaman sebelumnya. API Rate Limiting & Scalability Patterns di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 3 dari 4.

Berapa lama pelajaran “Menangani Pelampauan Batas Laju” memakan waktu?

Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.

Bisakah aku menulis dan menjalankan kode dalam pelajaran API Rate Limiting & Scalability Patterns ini?

Ya. Setiap pelajaran API Rate Limiting & Scalability Patterns menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.

Semua pelajaran dalam kursus ini

Rancangan Pembatas Laju Dalam Memori
Pembatasan Laju Terdistribusi dengan Redis
Menangani Pelampauan Batas Laju
Menguji dan Memantau Pembatas Laju Anda

← Kembali ke API Rate Limiting & Scalability Patterns