04 / 06

How do you implement rate limiting in a Go API — per user, per IP, and globally?

Difficulty: 5/10
per-user limit, IP-based limit, global throttling

Use the token bucket algorithm from golang.org/x/time/rate for single-instance rate limiting. For distributed rate limiting across multiple instances, use Redis with atomic Lua scripts.

Rate limiting middleware
Rate limiting strategies
  1. 1

    Token bucket (golang.org/x/time/rate): allows bursts up to bucket capacity, refills at a constant rate

  2. 2

    Sliding window: more accurate than fixed window, prevents burst at window boundaries

  3. 3

    Per-user rate limits are more fair than per-IP for authenticated APIs — use user ID from JWT

  4. 4

    Redis-cell (redis module) or Lua scripts for distributed rate limiting across service instances

  5. 5

    Return Retry-After header with 429 responses to help well-behaved clients back off

Scenario Questions

0-2 years experience

  1. 1We have a simple Go HTTP handler that returns JSON. How would you add a per‑user rate limit of 100 requests per minute using only the standard library?
  2. 2If a client exceeds the per‑IP limit, which HTTP status code would you return and why?
  3. 3What could go wrong if you store request counters in a global map without any synchronization?

2-5 years experience

  1. 1You need to enforce per‑user, per‑IP, and a global request cap in a microservice running on multiple instances behind a load balancer. Which approach would you take and what trade‑offs does it have?
  2. 2During load testing you notice legitimate traffic being throttled unexpectedly. How would you debug the rate‑limiting logic?
  3. 3Why is using time.Sleep inside a handler to enforce limits a bad idea?

5-8 years experience

  1. 1Design a rate‑limiting middleware that can scale to thousands of requests per second, supports burst traffic, and works across distributed instances. Which algorithm and storage would you choose?
  2. 2How would you handle a user behind a NAT who shares an IP with many other users while still enforcing per‑user limits?
  3. 3Compare using a Redis Lua script versus an in‑memory token bucket for global limits in terms of latency and consistency.

8+ years experience

  1. 1Our platform is moving from a monolith to independent services. How would you evolve the existing rate‑limiting implementation to a centralized policy service without breaking existing clients?
  2. 2What governance and observability practices would you put in place to keep rate‑limit policies consistent across teams and allow safe updates?
  3. 3If a new regulation requires per‑region request caps, how would you extend the current design while preserving performance?

Follow-up Questions

  • What metrics would you expose to monitor the effectiveness of your rate limiter?
  • How would you handle a sudden traffic spike that pushes you over the limits?
  • Can you discuss the trade‑off between accuracy and latency in your chosen implementation?
Share

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.