Fixed Window vs. Sliding Window Rate Limiting in .NET

🔍 1. Fixed Window Rate Limiting (in .NET)

What it is

The Fixed Window algorithm counts requests within a strict time window (like a box of time). When the window resets, the count resets too.

Example

Limit: 10 requests per minute.
Every minute (e.g., from 10:00:00 to 10:01:00), a new window opens.
If a client makes 10 requests at 10:00:05, they are allowed.
The next request (11th) before 10:01:00 will get blocked (HTTP 429 error).
At 10:01:00, the window resets and they can make requests again.

In .NET

options.AddSlidingWindowLimiter("sliding", opt =>
{
    opt.Window = TimeSpan.FromMinutes(1);   // 1-minute rolling window
    opt.PermitLimit = 10;                  // 10 requests allowed in the last minute
    opt.SegmentsPerWindow = 4;             // divide into 4 parts (15 seconds each)
    opt.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
    opt.QueueLimit = 2;
});

Pros

✔️ Very simple and fast to implement.
✔️ Good for low-traffic or non-critical APIs.

Cons

❌ Allows “burst traffic” at the start of the window (all 10 requests may come instantly).
❌ Not very "smooth" — users may hit the limit early and wait for the whole window.

🔍 2. Sliding Window Rate Limiting (in .NET)

What it is

The Sliding Window algorithm spreads the limit over a rolling period, not tied to a fixed block of time. It calculates how many requests were made in the last X minutes — no matter when the requests came.

Example

Limit: 10 requests per minute (rolling).
If 10 requests were made between 10:00:30 and 10:01:30, the limit applies based on that rolling window — not the wall clock.
This avoids a sudden "burst" problem and gives a smoother, fairer limit.

In .NET

options.AddSlidingWindowLimiter("sliding", opt =>
{
    opt.Window = TimeSpan.FromMinutes(1);   // 1-minute rolling window
    opt.PermitLimit = 10;                  // 10 requests allowed in the last minute
    opt.SegmentsPerWindow = 4;             // divide into 4 parts (15 seconds each)
    opt.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
    opt.QueueLimit = 2;
});

SegmentsPerWindow: The window is divided into smaller parts (helps tracking requests better).

Pros

✔️ Fairer and smoother — no sudden resets or spikes.
✔️ Prevents "burst" requests at the start of each minute.

Cons

❌ Slightly more memory and CPU usage (to track rolling windows).
❌ Complex to implement manually (but .NET does this for you).

✅ When to Use Which?

Scenario	Fixed Window	Sliding Window
Simple internal APIs	✅ Good	❌ Overkill
Public APIs used by 1000s of users	❌ Not Recommended	✅ Better
Need smooth traffic flow (e.g., payment gateway)	❌ Bad for bursts	✅ Ideal
Want easy implementation without extra load	✅ Very Easy	❌ Slightly heavy

📝 Interview Perspective

Q: What is the key difference between Fixed and Sliding window algorithms in API Rate Limiting?

Fixed Window resets the counter after each period (e.g., every minute).
Sliding Window checks requests across a rolling period, making limits smoother and avoiding bursts.
Sliding is better for high-traffic public APIs, while Fixed is good for simple, low-risk endpoints.

🔗 Real Example: Login API in .NET

Fixed Window

// Allow 5 login attempts every 60 seconds
options.AddFixedWindowLimiter("loginFixed", opt =>
{
    opt.Window = TimeSpan.FromSeconds(60);
    opt.PermitLimit = 5;
});

Sliding Window

// Allow 5 login attempts in any rolling 60 seconds
options.AddSlidingWindowLimiter("loginSliding", opt =>
{
    opt.Window = TimeSpan.FromSeconds(60);
    opt.PermitLimit = 5;
    opt.SegmentsPerWindow = 6;  // 10 seconds each
});

🎯 Summary

Fixed Window	Sliding Window
Simple, less resource-hungry	Smooth, prevents burst requests
Allows initial bursts	Spreads requests over time
Good for small/private APIs	Best for public APIs, payment, login
Reset happens strictly by time	Reset happens by rolling calculation

If you want, I can

Build a full sample .NET app demonstrating both types.
Help you prepare exact interview answers.
Show how to apply rate limiting per user/IP dynamically.