{
  "id": 19677979,
  "title": "System Design, Plainly — Part 6: Rate Limiting",
  "url": "https://urgent.news/2026/11/12/system-design-plainly-part-6-rate-limiting",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-11-12T16:59:57.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/danielsamfdo/system-design-plainly-part-6-rate-limiting-4585"
  },
  "original_language": "en",
  "account": "<Part 6: Rate Limiting>\n\nOn a Tuesday morning at 2:17 AM, an e-commerce platform's API went down due to a rate limiter issue. The limiter was designed to allow N requests per period but had allowed a burst of requests at the boundary between two time windows, overwhelming downstream services. The limiter was counting requests correctly, but the algorithm was counting the wrong way, letting twice the limit through in two seconds.\n\nThere are several ways to enforce rate limiting, each with different algorithms:\n\n1. Fixed window counter: This method uses one counter per caller per clock window, such as per calendar minute. The counter is incremented on arrival, rejected if past the limit, and reset to zero at the next minute. While simple, this method fails at the window boundary, allowing twice the limit in a short period.\n\n2. Sliding window log: This method stores a timestamp for every accepted request and counts how many fall within the last 60 seconds. It is exact and avoids the boundary issue of the fixed window counter. However, it requires memory proportional to the limit, which can be significant for high limits and large user bases.\n\n3. Token bucket: This method holds a bucket of C tokens and refills them at a rate of R tokens per second. Each request takes one token, and an empty bucket results in a 429 response. The bucket allows bursts, with the long-run rate never exceeding R. The token bucket is the default for public APIs, as bursts are normal client behavior.\n\n4. Leaky bucket: This method is similar to the token bucket, but it holds tokens and releases them at a constant rate. Unlike the token bucket, the leaky bucket does not allow bursts. It ensures perfectly smooth output but may make callers wait if the bucket is nearly empty.\n\nWhen choosing a rate limiting algorithm, consider the specific needs and constraints of the system. Smaller limits and high precision may require the sliding window log, while larger limits and acceptable approximations may benefit from the sliding window counter or token bucket. The choice ultimately depends on the desired balance between accuracy, memory usage, and the ability to handle bursts of requests.",
  "summary": "At 2:17 AM on a Tuesday, an e-commerce platform's API went down. The incident report later named the root cause: not a traffic spike, not a bad deploy — a rate limiter that had allowed a burst of requests through at exactly the boundary between two time windows, overwhelming the downstream services it was supposed to protect. The limiter was doing its job by every metric it kept. It was counting…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}