0Pricing
API Rate Limiting & Scalability Patterns · Lezione

Contatore a finestra fissa

Scopra come funziona l'algoritmo del contatore a finestra fissa, la sua semplicità e i potenziali svantaggi nella gestione dei picchi di traffico.

Contatore a finestra fissa è una lezione API Rate Limiting & Scalability Patterns gratuita su CoddyKit. Questa è la lezione 1 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento API Rate Limiting & Scalability Patterns, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso API Rate Limiting & Scalability Patterns include 4 lezioni in totale.

Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.

Why Algorithms?

Rate limiting isn't just a 'yes' or 'no' check. It relies on smart algorithms to manage traffic. These algorithms decide how and when to allow or deny requests, ensuring fairness and stability.

We'll start with one of the simplest: the Fixed Window Counter.

Fixed Window Counter: The Idea

The Fixed Window Counter is a straightforward rate limiting algorithm. It works by dividing time into fixed, non-overlapping windows.

  • Each window has its own request counter.
  • Once a request comes in, the counter for the current window increments.
  • If the counter exceeds a predefined limit within that window, further requests are blocked.

How It Counts

Imagine a clock. For every minute (our fixed window), we allow, say, 10 requests. When a new minute starts, the counter resets to zero.

  • Window: A specific time period (e.g., 60 seconds).
  • Limit: Maximum requests allowed in that window.
  • Counter: Tracks requests within the current window.

It's like a bouncer at a club, letting in only a set number of people each hour, then resetting the count for the next hour.

Example: 10 RPS Limit

Let's say our limit is 10 requests per second (RPS).

  • Window 1 (0-1s): 7 requests made. 3 requests remaining.
  • Window 2 (1-2s): 12 requests made. First 10 allowed, next 2 blocked.
  • Window 3 (2-3s): 5 requests made. All allowed.

At the start of each new second, the counter resets, regardless of activity in the previous second.

Basic Counter Logic

Here's a simple Java class simulating a request counter. This forms the foundation of our rate limiter. It keeps track of requests within a defined window.

import java.time.Instant;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicInteger;

class FixedWindowCounter {
    private final int limit;
    private final long windowSizeMillis; // e.g., 60_000 for 1 minute
    private final ConcurrentHashMap<Long, AtomicInteger> counters;

    public FixedWindowCounter(int limit, long windowSizeMillis) {
        this.limit = limit;
        this.windowSizeMillis = windowSizeMillis;
        this.counters = new ConcurrentHashMap<>();
    }

    public boolean allowRequest(String userId) {
        long currentWindowKey = Instant.now().toEpochMilli() / windowSizeMillis;
        
        // Get or create counter for the current window
        AtomicInteger counter = counters.computeIfAbsent(
            currentWindowKey, k -> new AtomicInteger(0)
        );

        // Increment and check if within limit
        return counter.incrementAndGet() <= limit;
    }
}

public class Main {
    public static void main(String[] args) {
        System.out.println("FixedWindowCounter class defined.");
        System.out.println("Ready to use in next example.");
    }
}

Testing the Window

Let's use our FixedWindowCounter class to simulate requests and see how it limits them within a 1-second window. Observe how requests are counted and then reset for the next window.

import java.time.Instant;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicInteger;

// The FixedWindowCounter class
class FixedWindowCounter {
    private final int limit;
    private final long windowSizeMillis;
    private final ConcurrentHashMap<Long, AtomicInteger> counters;

    public FixedWindowCounter(int limit, long windowSizeMillis) {
        this.limit = limit;
        this.windowSizeMillis = windowSizeMillis;
        this.counters = new ConcurrentHashMap<>();
    }

    public boolean allowRequest(String userId) {
        long currentWindowKey = Instant.now().toEpochMilli() / windowSizeMillis;
        AtomicInteger counter = counters.computeIfAbsent(
            currentWindowKey, k -> new AtomicInteger(0)
        );
        return counter.incrementAndGet() <= limit;
    }
}

public class Main {
    public static void main(String[] args) throws InterruptedException {
        // Allow 3 requests per 1-second window
        FixedWindowCounter limiter = new FixedWindowCounter(3, 1000); 

        System.out.println("--- First Window ---");
        for (int i = 0; i < 5; i++) {
            boolean allowed = limiter.allowRequest("user1");
            System.out.println("Request " + (i + 1) + ": " + (allowed ? "ALLOWED" : "BLOCKED"));
        }

        // Wait for next window to start
        Thread.sleep(1100); 

        System.out.println("\n--- Second Window ---");
        for (int i = 0; i < 2; i++) {
            boolean allowed = limiter.allowRequest("user1");
            System.out.println("Request " + (i + 1) + ": " + (allowed ? "ALLOWED" : "BLOCKED"));
        }
    }
}

Fixed Window: Pros

The Fixed Window Counter algorithm is popular for its simplicity and efficiency in certain scenarios.

  • Easy to Implement: Requires minimal logic and data structures (just a counter and a timestamp).
  • Low Resource Usage: Very little memory and CPU overhead per window.
  • Predictable: The reset at the start of each window is clear and easy to understand.

It's a good choice for basic rate limiting where precision isn't paramount.

The Burst Problem

Despite its simplicity, the Fixed Window Counter has a significant drawback: it can allow twice the intended rate limit at the window boundaries.

Imagine a limit of 10 requests per minute.

  • A user makes 10 requests at 0:59 (end of window 1).
  • They then make 10 more requests at 1:01 (start of window 2).

This means 20 requests were made within a very short 2-minute period, effectively doubling the rate in a small burst.

Boundary Bursts

Let's visualize the burst issue with a 5 requests/minute limit.

  • Window 1 (0:00 - 0:59): 5 requests sent at 0:58. (Allowed)
  • Window 2 (1:00 - 1:59): 5 requests sent at 1:01. (Allowed)

In just 3 minutes (0:58 to 1:01), 10 requests were allowed. This is effectively 5 requests in ~3 seconds, not 5 requests per minute, defeating the purpose of the limit.

This 'burst' can overwhelm your system if not accounted for.

Fixed Window Check

Consider a fixed window rate limiter set to 5 requests per minute. The current time is 0:59:30. A user has already made 4 requests in the current window (0:00:00 to 0:59:59).

They then make another 3 requests at 0:59:45. Immediately after, at 1:00:05 (5 seconds into the next window), they make 3 more requests.

Recap: Fixed Window

We've explored the Fixed Window Counter algorithm:

  • It divides time into distinct, non-overlapping windows.
  • Each window has a request counter that resets at the start of a new window.
  • It's simple to implement and understand.
  • Its main drawback is the burst problem, where requests at window boundaries can effectively double the rate in a short period.

Next, we'll look at algorithms that try to smooth out these bursts!

Domande Frequenti

La lezione «Contatore a finestra fissa» è gratuita?

Sì — il testo completo di «Contatore a finestra fissa» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso API Rate Limiting & Scalability Patterns, passa a CoddyKit PRO. Il corso API Rate Limiting & Scalability Patterns include 4 lezioni in totale.

Cosa imparerò in «Contatore a finestra fissa»?

Scopra come funziona l'algoritmo del contatore a finestra fissa, la sua semplicità e i potenziali svantaggi nella gestione dei picchi di traffico. Eserciti API Rate Limiting & Scalability Patterns con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare API Rate Limiting & Scalability Patterns?

Non è richiesta alcuna esperienza precedente. API Rate Limiting & Scalability Patterns su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 1 di 4.

Quanto tempo richiede la lezione «Contatore a finestra fissa»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione API Rate Limiting & Scalability Patterns?

Sì. Ogni lezione API Rate Limiting & Scalability Patterns include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Contatore a finestra fissa
  2. Approfondimento sull'algoritmo leaky bucket
  3. Meccanismi dell'algoritmo token bucket
  4. Scegliere l'algoritmo giusto
← Torna a API Rate Limiting & Scalability Patterns