1. Algorithmic Requirements
An in-memory rate limiter must accept or reject an incoming request based on a client key (IP or User ID) and a defined quota (e.g. 100 requests per 60 seconds).
The sliding window log tracks each request timestamp, ensuring exact enforcement across any arbitrary 60-second window without the boundary-burst flaw of fixed-window counters.
2. Thread-Safety & Memory Optimization
Under concurrent multi-threaded requests, multiple threads may attempt to append timestamps simultaneously. Using a coarse synchronized lock slows throughput. Instead, we use fine-grained synchronized blocks per client key or atomic concurrent collections.
3. TypeScript Code Implementation
Below is an efficient sliding window rate limiter implementation using a deque structure:
export class SlidingWindowRateLimiter {
private userWindows = new Map<string, number[]>();
constructor(private maxRequests: number, private windowSizeMs: number) {}
public allowRequest(userId: string): boolean {
const now = Date.now();
const windowStart = now - this.windowSizeMs;
if (!this.userWindows.has(userId)) {
this.userWindows.set(userId, []);
}
const timestamps = this.userWindows.get(userId)!;
// Evict expired timestamps
while (timestamps.length > 0 && timestamps[0] <= windowStart) {
timestamps.shift();
}
if (timestamps.length < this.maxRequests) {
timestamps.push(now);
return true;
}
return false;
}
}Model this architecture on the HLDForge Canvas
Turn static box diagrams into living, collaborative systems. Drag and drop microservices, Kafka clusters, and cache tiers. Run automated SPOF detection and STRIDE threat modeling in real time.
Written by HLDForge Architecture Team
Lead Systems Software Engineer
The HLDForge Architecture Team publishes practical engineering guides, real-world case studies, and high-concurrency blueprints to help engineers build scalable and fault-tolerant software.