System Design

System-design interview: name all 8 steps of the spine in order

1 Functional reqs (pick top ~3, ignore rest) · 2 Non-functional reqs QUANTIFIED (p95<200ms, not "fast") · 3 Capacity estimate (back-of-envelope QPS/storage/bandwidth) · 4 API design (concrete request/response contracts) · 5 Data model (entities/schema; structured vs blob → storage choice) · 6 High-level architecture (simplest design that meets reqs, then diagram) · 7 Deep dive: scaling & bottlenecks (shard/cache/fan-out/hot-key) · 8 Tradeoffs (what sacrificed for what; monitoring/failure/rollback)

Step 1 of the SD spine — Functional requirements: what's the move?

State the top ~3 features explicitly and explicitly SAY you're ignoring the rest. Scoping down is a positive signal, not a gap.

Step 2 of the SD spine — Non-functional requirements: what's the move?

Quantify everything: latency as a percentile (p95<200ms), availability (99.9%), consistency model, durability, read:write ratio, scale (DAU/QPS). "Fast/scalable" without numbers is the weak-signal trap.

Step 7 of the SD spine — Deep dive levers (name them):

Sharding/partitioning · caching layers · fan-out (write vs read) · replication · hot-key / celebrity problem · load balancing · async queues · CDN. Pick the 1-2 that bind THIS design's bottleneck.

ML system-design variant: how does the spine change?

Same shell, but front-load the pipeline shape: candidate generation → ranking → re-ranking · separate training vs serving · add an experiment + monitoring plan. (How it's GRADED differently — eval over diagram — is its own card in the ML-SD set.)

Two-stage recommendation/retrieval spine

Candidate generation (cheap, high-recall, narrow millions→hundreds) → Ranking (expensive model, precision, order the shortlist) → Re-ranking (business rules, diversity, freshness, dedup). Cheap-and-wide then expensive-and-narrow.

RAG pipeline spine — name every stage in order

Ingest → Chunk → Embed → Index → Retrieve → Rerank → Generate. Seven stages; know which stage a given failure lives in (the two failure axes get their own cards in the LLM set).

Hallucination-mitigation framework (name the levers)

Grounding (force answer from retrieved context) · NLI cross-check (verify claim entails from source) · self-consistency (sample N, vote) · citation (make it cite spans) · confidence-routing (escalate/abstain when unsure). Framing: "managed, not eliminated."

Fan-out on write vs fan-out on read — when which?

Write (precompute each follower's feed on post): fast reads, expensive for high-follower accounts. Read (assemble feed at query time): cheap writes, slow reads. Real answer = hybrid: fan-out-on-write for normal users, fan-out-on-read for celebrities.

The "celebrity" / hot-key problem

One key (a celeb, a viral item) gets disproportionate traffic, overloading its shard/cache. Fixes: don't fan-out-on-write for them (pull at read time) · replicate the hot key across nodes · dedicated cache. Naming this unprompted is a senior signal.

SD closing checklist (step 8) — what to always mention

Monitoring/observability (metrics, alerts, dashboards) · failure modes + graceful degradation · rollback/deploy strategy · the explicit tradeoff you made and what you sacrificed. Ending on tradeoffs > ending on a diagram.

SD ladder order for practice (weakness→strength)

1 URL shortener (pure infra, hardest for me, drive cold) · 2 news feed (fan-out) · 3 recsys (ML, real ALS experience) · 4 RAG design (near-own, my lane). Attack the infra I lack first; end on my turf.