.NET  

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?

A

  • 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.