Lesson 3 of 15
32. Design a Rate Limiter as a Service

32.2 How big is this, really?

3 min read+10 XP

Step 2: Estimates (5 minutes)

Assume about 100 bytes per bucket in Redis (key, tokens, timestamp, overhead) and one Redis operation per check.

WhatWorkingResult
Checks a second at peakgiven200,000
Redis operations a second200,000 × 1 script call200,000
Redis shards200,000 ÷ 50,000 (assumed safe ops per shard, leaving headroom)4 shards, each with a replica
Memory for buckets10 million × 100 bytes≈ 1 GB: tiny
Network200,000 × ~200 bytes request + reply≈ 40 MB/s: fine
Added latencyone same-zone round trip + script≈ 0.5-1 ms typical

What the numbers say, out loud:

  • "Memory is trivial. 1 GB of counters. Storage isn't the problem."
  • "200,000 operations a second is the real load, so the counter store must be sharded and every check must be one round trip."
  • "Latency matters more than size: the limiter sits on every request, so it must be in the same zone as the callers, and callers need tight timeouts."

Interviewer pushback:

  • "Why 50,000 operations per shard when Redis can do much more?" → Lua scripts cost more than a plain GET, traffic spikes, and we want room to lose a shard. It's an assumption to check with a load test.
  • "Could we skip Redis and count in each server's memory?" → Only as a backstop. With a load balancer spreading one client across many servers, local counts can't enforce a shared limit (Chapter 25's 55-of-100 example).

Memory code: "Tiny memory, huge rate, one round trip."