API Design & Rate Limiting

How you expose a system matters as much as how you build it. Clean API design and rate limiting come up in nearly every system design round.

REST Fundamentals Worth Restating

Resource-oriented URLs, correct HTTP verbs and status codes, and pagination for list endpoints. Interviewers notice when candidates default to a single POST /doEverything endpoint instead of resource-based design.

Why Rate Limiting Matters

Rate limiting protects your system from being overwhelmed by a single client — whether malicious or accidentally misbehaving — and ensures fair usage across all clients.

Common Algorithms

Fixed window counters are simple but allow bursts at window boundaries. Sliding window logs are precise but memory-heavy. Token bucket allows controlled bursts while enforcing an average rate — the most commonly used approach in production systems, and a safe default to name in an interview.

The fixed-window burst problem is worth being able to explain concretely: if a client is limited to 100 requests per minute, they could send 100 requests in the last second of one window and another 100 in the first second of the next — 200 requests in two seconds, technically within the stated limit. Sliding window and token bucket both address this, which is why they're generally preferred in practice.

Versioning Your API

Breaking changes are inevitable as a system evolves. URL-based versioning (/v1/, /v2/) is the simplest and most widely understood approach, and it's rarely wrong to default to it unless the interviewer pushes for alternatives like header-based versioning.

Where to Enforce Rate Limits

Rate limiting can live at the API gateway (before requests even reach your services) or within individual services. Gateway-level limiting is simpler to reason about and protects every downstream service uniformly — a good default to mention unless a specific service needs a tighter, custom limit.

Returning the Right Signal to the Client

A well-designed rate-limited API returns a 429 status code along with headers indicating the limit, how many requests remain, and when the window resets — this lets well-behaved clients back off gracefully instead of hammering the endpoint with retries. Mentioning this level of detail is a small thing that distinguishes candidates who've actually built and operated an API from those who've only studied the concept.