Master Sliding Window Rate Limiting in Java with Simple Code

In this article, the author presents a simple implementation of a sliding window rate‑limiting algorithm in Java, suitable for single‑machine environments, and explains how to adapt it for distributed scenarios using Redis.

package cn.dijia478.util;

import java.time.LocalTime;
import java.util.LinkedList;
import java.util.List;
import java.util.Map;
import java.util.Random;
import java.util.concurrent.ConcurrentHashMap;

/**
 * Sliding window rate‑limiting utility
 * This tool works only for single‑machine versions; for global rate limiting, the same idea can be implemented with Redis List.
 */
public class SlideWindow {

    /** Mapping from queue ID to a list of timestamps; each list stores the timestamps of passed requests. */
    private volatile static Map<String, List<Long>> MAP = new ConcurrentHashMap<>();

    private SlideWindow() {}

    public static void main(String[] args) throws InterruptedException {
        while (true) {
            // Allow at most 2 passes in any 10‑second interval
            System.out.println(LocalTime.now().toString() + SlideWindow.isGo("ListId", 2, 10000L));
            // Sleep 0‑10 seconds
            Thread.sleep(1000 * new Random().nextInt(10));
        }
    }

    /**
     * Sliding window rate‑limiting algorithm
     * Determines whether a request is allowed within the specified time window and count.
     *
     * @param listId     Queue identifier
     * @param count      Maximum allowed passes
     * @param timeWindow Time window size (milliseconds)
     * @return true if the request can pass, false otherwise
     */
    public static synchronized boolean isGo(String listId, int count, long timeWindow) {
        long nowTime = System.currentTimeMillis();
        // Retrieve or create the list for the given queue ID
        List<Long> list = MAP.computeIfAbsent(listId, k -> new LinkedList<>());
        // If the list is not full, allow the request and add the current timestamp at the head
        if (list.size() < count) {
            list.add(0, nowTime);
            return true;
        }
        // List is full; get the earliest timestamp (the one at position count‑1)
        Long farTime = list.get(count - 1);
        // If the time difference is within the window, reject the request
        if (nowTime - farTime <= timeWindow) {
            return false;
        } else {
            // Otherwise, remove the oldest timestamp, add the current one at the head, and allow the request
            list.remove(count - 1);
            list.add(0, nowTime);
            return true;
        }
    }
}

Running the program shows that no more than two requests are allowed in any ten‑second interval. The article then illustrates the sliding‑window principle with a series of diagrams:

1. The queue is initially empty; the first event at 1 s adds its timestamp at position 0.

2. The second event arrives at 2.8 s; because the size is still below the limit, its timestamp is inserted at the head, pushing the previous one back.

3. After three more events the queue reaches the limit (size 5). When the sixth event arrives at 8 s, the algorithm compares the oldest timestamp (position 4) with the current time.

4. The time difference is 7 s, which is less than the 10‑second window, so the request is rejected.

5. Even if many more events arrive within the same window, they will continue to be rejected until the oldest timestamp moves out of the window.

6. When an event finally arrives after the window (e.g., at 11.1 s), the time difference exceeds 10 s, the oldest timestamp is removed, the new one is added, and the request is allowed.

The essential idea is to convert a time‑based limit into a count‑based limit and then enforce a time constraint on the oldest entry, thereby achieving sliding‑window rate limiting.