Panic mode

Interview prep: 24h speed-run

Your interview is tomorrow. You don't have time to learn anything new. This page is the minimum you need to revisit so the patterns are top-of-mind.

The answer template (memorize this)

Almost every system design interview follows this flow. Use it to organize what you say.

1
Functional requirements (3 min)
What does the system do? What does it NOT do? Get the scope pinned down with the interviewer. Always confirm explicitly.
2
Non-functional requirements (2 min)
Latency targets. Availability target. Consistency requirements. Read-heavy vs write-heavy. Global vs single region.
3
Back-of-envelope estimation (5 min)
DAU → QPS → storage/yr → bandwidth. Don't skip this. It's how you pick the architecture. Drill it here.
4
API design (3 min)
2-4 endpoints. Method, path, request, response. Don't bikeshed REST vs gRPC. Pick one and move on.
5
Data model (5 min)
Tables / collections / streams. Primary keys. Indexes. Sharding key. SQL vs NoSQL, justify briefly.
6
High-level architecture (5 min)
Draw the boxes and arrows. Client → CDN → LB → API gateway → services → caches → datastores → queues.
7
Deep dive (10-15 min)
Interviewer picks 1-2 components to drill. Be ready to defend choices: "why Cassandra not Postgres?"
8
Tradeoffs & scale (5 min)
"What if 10x?" "What if Redis dies?" "What about consistency?" This is where you actually score.

Cache aside, read replicas, write-once-read-many.

Precompute timelines, S3 for media, push to follower caches.

Push for normals, pull for celebs, merge at read.

WebSocket gateway tier, Cassandra log, push for offline.

Geohashing, in-memory geo-index, dispatcher per region.

Partitions = scale unit. ISR = durability. Consumer groups = parallelism.

If any of these makes you blank, click the linked concept and re-read it.

1. Walk me through CAP. Which side does most production traffic actually pick?
cap theorem
2. What's idempotency and why does every retry-able API need it?
idempotency
3. Why consistent hashing instead of mod-N? What happens when you add a node?
consistent hashing
4. Bloom filter: when, why, what's the math?
bloom filter
5. Cache-aside vs write-through vs read-through: pick one and defend.
caching
6. What's a quorum write and why does it give you tunable consistency?
quorum
7. Sharding: by what key, and what's the failure mode of a bad choice?
sharding
8. How would you rate-limit an API across 100 instances? Where do counters live?
caching
9. Circuit breaker: what state does it carry, and how does it close?
circuit breaker
10. WebSocket vs long-polling vs SSE: when do you actually need WS?
polling vs websockets

✗Jump to architecture without confirming requirements. You'll design the wrong system.
✗Use NoSQL because "it scales." Have a real reason: write throughput, schema flexibility, access pattern.
✗Refuse to do estimation. The interviewer is checking whether you can. Skipping signals you can't.
✗Add Kafka to everything. Sometimes a synchronous call is fine and adding a queue is over-engineering.
✗Be precious about your initial design. Senior engineers iterate; they don't defend.
✗Stay silent while thinking. Narrate. The interviewer needs to follow your reasoning, not just see your final answer.