Interview Cheat Sheet
A one-page reference for everything you need in the API design step of a system design interview.
1. Protocol Decision Matrix
| Protocol | Best For | Data Format | When to Pick |
|---|---|---|---|
| REST | Public APIs, CRUD, web/mobile clients | JSON over HTTP | Default choice — use unless you have a reason not to |
| GraphQL | Diverse clients needing different data | JSON over HTTP (single endpoint) | Interviewer mentions over-fetching, mobile vs web |
| gRPC | Internal microservice communication | Protocol Buffers over HTTP/2 | Interviewer mentions service-to-service, performance |
| WebSockets | Bidirectional real-time (chat, gaming) | Any over persistent TCP | Both client and server send messages |
| SSE | Server-push (notifications, feeds) | Text over HTTP | Only server pushes, client listens |
Default: REST for public + gRPC for internal.
2. HTTP Methods Quick Reference
| Method | Action | Safe? | Idempotent? | Has Body? | Example |
|---|---|---|---|---|---|
| GET | Read | Yes | Yes | No | GET /events/123 |
| POST | Create | No | No | Yes | POST /events/123/bookings |
| PUT | Replace/Create | No | Yes | Yes | PUT /users/123 |
| PATCH | Partial update | No | No | Yes | PATCH /users/123 |
| DELETE | Remove | No | Yes | Optional | DELETE /bookings/123 |
Idempotency is an implementation contract (RFC 9110), not a magic property of the verb.
3. Status Code Cheat Sheet
| Code | Meaning | When to Use |
|---|---|---|
| 200 | OK | Successful GET, PUT, PATCH, DELETE |
| 201 | Created | Successful POST that creates a resource |
| 204 | No Content | Successful DELETE with no response body |
| 400 | Bad Request | Invalid input, malformed JSON |
| 401 | Unauthorized | Missing or invalid authentication |
| 403 | Forbidden | Authenticated but not authorized |
| 404 | Not Found | Resource doesn't exist |
| 409 | Conflict | Duplicate resource, version conflict |
| 429 | Too Many Requests | Rate limit exceeded |
| 500 | Internal Server Error | Unhandled server failure |
Interview shortcut: Just say "2xx for success, 4xx for client errors, 5xx for server errors."
4. API Design Recipe (6 Steps, 5 Minutes)
- Identify core entities from requirements → these are your resources
- Map to REST endpoints with plural nouns:
/events,/bookings,/users - Define HTTP methods for each resource: GET, POST, PUT/PATCH, DELETE
- Add pagination for all list endpoints:
?limit=20&cursor=abc - Call out auth requirements: public vs authenticated vs authorized
- Move on to high-level design
5. Pagination Quick Reference
| Approach | How It Works | Pros | Cons | Use When |
|---|---|---|---|---|
| Offset | ?offset=20&limit=10 |
Simple, jump to any page | Data shift on writes, slow at high offsets | Admin dashboards, static data |
| Cursor | ?cursor=abc&limit=10 |
Stable under writes, fast | No page jumping | Feeds, real-time data, high-write systems |
6. Authentication Quick Reference
| Mechanism | How It Works | Best For |
|---|---|---|
| Session/Cookie | Server stores session, client sends cookie | Traditional web apps |
| API Key | Long random string in header | Server-to-server, 3rd party devs |
| JWT | Stateless token with user info + signature | User-facing apps, distributed systems |
| OAuth 2.0 | Client ID + Secret → Bearer Token (JWT) | Developer APIs (industry standard) |
User identity always from JWT, never from request body.
7. Common Anti-Patterns to Avoid
- Verbs in URLs (
/getUser→ useGET /users/{id}) - User ID in request body (extract from JWT)
- Tenant ID in URL path (encode in JWT)
- No pagination on list endpoints
- Boolean fields that should be enums (
is_active→status: "active") - Auto-increment IDs exposed publicly (use UUIDs)
- Leaky error messages (generic externally, detailed in logs)
- Chatty APIs (14 requests for one page → composite endpoints)
- Mirroring database tables in API (design around business entities)
- No async pattern for long-running operations (use 202 + polling)
- Ignoring ETags and caching (use Cache-Control, If-None-Match)
8. Async & Caching Quick Reference
| Pattern | Flow | Key Status Codes |
|---|---|---|
| Async operation | POST → 202 Accepted → poll status URL → 303 See Other to result | 202, 303 |
| Conditional GET | GET with If-None-Match: "etag" → 304 Not Modified (use cache) |
304 |
| Optimistic concurrency | PUT with If-Match: "etag" → 412 Precondition Failed (stale) |
412 |
| HTTP caching | Cache-Control: max-age=600, private |
N/A (response header) |
9. Interview Power Moves
-
"I'll use REST for the public API and gRPC for internal service communication." Shows you know the mixed-protocol pattern used by Google, Netflix, and most large systems.
-
"User identity comes from the JWT token, not the request body." Demonstrates security awareness that many candidates miss.
-
"I'll add idempotency keys for the booking/payment endpoints." References Stripe's pattern — shows production experience.
-
"List endpoints use cursor-based pagination since this is a high-write system." Shows you understand the tradeoffs, not just the default.
-
"I'll use an enum for status instead of a boolean — it's more forward-compatible." Signals API evolution thinking.
-
"For the mobile and web clients with different data needs, we could use a BFF pattern." References Netflix's architecture — shows awareness of real-world solutions.
-
"For the video upload, I'll return 202 Accepted and provide a status polling endpoint." Shows async operation awareness — critical for long-running tasks.
-
"I'll use ETags with If-Match headers to prevent lost updates on collaborative resources." Demonstrates optimistic concurrency knowledge — relevant for any multi-user system.
10. Capacity Estimation for APIs
| Metric | Formula | Example |
|---|---|---|
| Average QPS | DAU x requests/user/day / 86,400 | 10M DAU x 20 req = ~2,300 QPS |
| Peak QPS | Average QPS x 3-5 | ~2,300 x 3 = ~7,000 QPS |
| Bandwidth | QPS x avg response size | 2,300 x 5KB = ~11.5 MB/s |
| Daily storage | Writes/day x avg payload | 1M POSTs x 2KB = ~2 GB/day |
| Data Size | Typical Value |
|---|---|
| Average JSON API response | 2-10 KB |
| JWT token | ~1 KB |
| Small image thumbnail | 20 KB |
| Compressed protobuf (gRPC) | 30-50% smaller than JSON |
Key phrase: "At 10M DAU with ~20 requests per user per day, we're looking at roughly 2,300 QPS average, peaking around 7K. A single well-tuned server handles ~5-10K QPS, so we'd need 2-3 API servers behind a load balancer."
11. Red Flags — What Never to Say
Interview Anti-Patterns
- "Cursor pagination" when the product needs "jump to page 45" — offset is the right choice there, acknowledge the trade-off
- "JWT for everything" without mentioning token revocation — JWTs can't be invalidated without a blacklist or short expiry
- "One big monolith REST API" for a system with fundamentally different client needs — mention BFF (Backend for Frontend) pattern
- "GraphQL because it's modern" — only justify it when clients have genuinely different data requirements
- "We'll version with /v2/" without explaining the migration strategy — mention sunset headers and deprecation timeline
- "No rate limiting needed" — every public API needs rate limiting, period
12. Baseline Architecture — The Safe Default
When you blank on where to start, draw this:
API Gateway handles cross-cutting concerns (auth, rate limiting, logging). Each service owns its database. Async communication via message queue for eventual consistency between services.