API Rate Limiting & Scalability Patterns · Ders

Hız Sınırının Aşılmasıyla Başa Çıkma

HTTP 429 durum kodları ve retry-after başlıkları dahil olmak üzere hız sınırı ihlallerine yanıt vermek için en iyi uygulamaları keşfedin.

Hız Sınırının Aşılmasıyla Başa Çıkma, CoddyKit'te ücretsiz bir API Rate Limiting & Scalability Patterns dersidir. Bu, 4 dersinin 3. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, API Rate Limiting & Scalability Patterns öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. API Rate Limiting & Scalability Patterns kursu toplamda 4 dersten oluşur.

Bu dersin bazı bölümleri henüz çevrilmemiş olup İngilizce olarak gösterilmektedir.

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.

Sıkça Sorulan Sorular

“Hız Sınırının Aşılmasıyla Başa Çıkma” dersi ücretsiz mi?

Evet — “Hız Sınırının Aşılmasıyla Başa Çıkma” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve API Rate Limiting & Scalability Patterns kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. API Rate Limiting & Scalability Patterns kursu toplamda 4 dersten oluşur.

“Hız Sınırının Aşılmasıyla Başa Çıkma” dersinde ne öğreneceğim?

HTTP 429 durum kodları ve retry-after başlıkları dahil olmak üzere hız sınırı ihlallerine yanıt vermek için en iyi uygulamaları keşfedin. API Rate Limiting & Scalability Patterns ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

API Rate Limiting & Scalability Patterns öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te API Rate Limiting & Scalability Patterns, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 3. dersidir.

“Hız Sınırının Aşılmasıyla Başa Çıkma” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu API Rate Limiting & Scalability Patterns dersinde kod yazıp çalıştırabilir miyim?

Evet. Her API Rate Limiting & Scalability Patterns dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

← API Rate Limiting & Scalability Patterns Sayfasına Dön