Practical Design Problems cheat sheet

1. Clarify: what, who, out of scope. Functional and non-functional.
2. Estimate: requests per second, storage, read:write ratio.
3. API: methods, status codes, errors, auth, pagination, idempotency.
4. Data model: what is stored, how it is read, keys and indexes.
5. Core design: the hard part, with alternatives and a choice.
6. Scale and fail: 10x traffic, a dependency down, hot keys, abuse.

Tip: 45 min: 5 clarify and estimate, 10 API and data, 15 core, 10 scale and failure, 5 wrap-up. Say: "A gives X but costs Y; given Z I choose A."

• Base62 (0-9a-zA-Z) is URL-safe. 7 characters give 62^7, about 3.5 trillion; 6B links use 0.17%.
• Base64 has +, / and =, which are not URL-safe.
• Retry loop: insert, catch Prisma P2002 (unique violation), make a new code, up to 5 tries.

• Analytics, expiry or edits: 302. Permanent links, least load: 301.
• Cache-aside in Redis with TTL no longer than the link's life. Negative-cache unknown codes (60 s) against scanners.
• Statuses: 404 unknown, 410 expired, 409 alias taken, 429 rate limited.
• Log clicks to a queue, never in the redirect request.

Watch out: Abuse: allow only http and https, check blocklists, block SSRF if you fetch the target, reject reserved aliases (api, admin), do not number codes in order.

• A limiter is key + rule + algorithm + shared state + response.
• Rate limit counts per period; quota counts a long period; concurrency limit counts running now; load shedding protects the system.
• Place it at the edge or gateway first, then app middleware for per-user rules.

-- ARGV: capacity, rate, nowMs, cost
tokens = min(capacity,
  tokens + elapsed * rate)
if tokens >= cost then
  tokens = tokens - cost
  allowed = 1
end
HSET key tokens ts
PEXPIRE key (idle keys vanish)

429 Too Many Requests
Retry-After: 18
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0

• Fail open for most APIs; fail closed for login, OTP, reset. Choose per rule, with a short timeout.
• Users behind one NAT: key on user id or API key, IP only as a wide outer layer. Trust X-Forwarded-For from trusted proxies only.

• Cursor is opaque base64url JSON. Validate it strictly, use parameterised queries; sign it with HMAC if needed.
• Put a fingerprint of sort and filters in the cursor. Keep full timestamp precision.
• Cap limit, set a default, cap offset depth. Backwards: flip comparison and sort, then reverse.
• Counts: approximate, cached, a counter table, or "10,000+".

1. Browser asks the API to upload (name, type, size). API validates, saves a PENDING row, returns a presigned URL.
2. Browser PUTs the bytes straight to object storage. Your servers stay out of the data path.
3. Storage event goes to a queue. Worker verifies, scans, makes thumbnails, sets READY or REJECTED.
4. Client polls or gets a push. A cleanup job removes stale PENDING rows.

• Large files: multipart, parts 5 MB to 5 GB, up to 10,000 parts, 5 TB object. Parallel parts, retry each, resume with ListParts.
• Add lifecycle rule AbortIncompleteMultipartUpload. CORS must expose ETag.

Watch out: Timeouts behind the load balancer mean bytes pass through it. Move to presigned direct upload.

• Serve from a separate domain, with X-Content-Type-Options: nosniff and Content-Disposition: attachment.
• Private files: private bucket and short-lived signed GET URLs.

• Pipeline: events, bus, notification service (recipients, preferences, dedupe, template), one queue per channel, workers.
• Table has UNIQUE (user_id, dedupe_key), a partial index on unread, and deliveries (notification_id, channel).
• Queues are at-least-once, so dedupe key plus idempotent senders plus DLQ.
• Digest, quiet hours (user time zone), frequency caps, critical messages always allowed.

3 tabs open

3 SSE connections; or a leader tab via BroadcastChannel; use HTTP/2

Broadcast to 1M

Fan-out on write (batched, throttled) or on read; hybrid; FCM topics

Offline user

Saved in-app list, Web Push, email or SMS fallback

Estimate

20M a day, about 230/s (peak 2,000), 100,000 open connections

The bell

List + unread count + stream; optimistic read; aria-live="polite"

1. Minimum 2 characters. Debounce 150 to 300 ms.
2. Check the per-prefix cache. On a miss, abort the previous request and fetch.
3. Ignore stale responses (compare the returned query). Cache by prefix.
4. Combobox ARIA, arrow keys, Enter, Escape. Handle IME. Highlight safely.

Tip: Serve GET /v1/suggest with Cache-Control: public, max-age=300 at the CDN. Fail softly: hide suggestions if slow.

• Idempotency key per intended payment, unique on (account_id, key), with request hash. Same key + same hash returns the saved response; different hash is 422; in progress is 409.
• Pass the key to the provider too. A timeout means unknown, not failed. Payments are a state machine with conditional UPDATE.
• Full jitter: delay = random(0, min(cap, base * 2^attempt)). Retry temporary errors on idempotent calls only; one layer only.
• Flag: hash(flagKey + userId) % 100 < percent. Same answer every time; raising 10 to 20 keeps the first 10%.
• Flags: evaluate locally, safe default, kill switch, audit log, owner and end date. Not for authorization.

get(k): v = map.get(k)
  map.delete(k); map.set(k, v)
put(k, v): map.delete(k)
  map.set(k, v)
  if (map.size > cap)
    delete map.keys().next().value