Before your system design interview (or before architecting a real system), run through this checklist:
[ ] I understand the 4-step blueprint and can apply it to any problem
[ ] I can estimate scale (QPS, storage, bandwidth) quickly
[ ] I know the trade-offs between SQL and NoSQL databases
[ ] I can explain caching strategies and eviction policies
[ ] I understand CAP theorem and consistency models
[ ] I can sketch a high-level architecture with 5—8 components
[ ] I can identify single points of failure and propose mitigations
[ ] I can design database schemas, indexes, and shard keys
[ ] I know common protocols (HTTP, WebSocket, gRPC) and when to use each
[ ] I have practiced 5+ case studies end-to-end
[ ] I can articulate trade-offs clearly and justify my decisions
Mindset & Approach
Think out loud: Interviewers want to see your thought process, not just the final diagram. Verbalize your reasoning, comparisons, and doubts.
Start simple, then optimize: Don't jump to a complex microservices architecture. Begin with a reasonable baseline and iterate.
Embrace trade-offs: There is no perfect system. Every decision involves a trade-off. Show that you understand both sides.
Handle failure: A system is only as good as its response to failure. Always discuss what happens when components crash, networks partition, or traffic spikes.
Know your numbers: Latency numbers every engineer should know (L1 cache: 0.5ns, mutex lock: 100ns, SSD random read: 100µs, network round-trip in same DC: 500µs, cross-continent: 150ms).
# Latency numbers to remember (approximate)
L1 cache reference: 0.5 ns
Branch mispredict: 5 ns
L2 cache reference: 7 ns
Mutex lock/unlock: 100 ns
Main memory reference: 100 ns
Compress 1KB with Zippy: 10,000 ns (10 µs)
Send 2KB over 1 Gbps: 20,000 ns (20 µs)
SSD random read: 100,000 ns (100 µs)
Read 1MB sequentially from SSD: 500,000 ns (500 µs)
Round trip in same datacenter: 500,000 ns (500 µs)
Read 1MB seq from disk: 20,000,000 ns (20 ms)
Round trip CA → Netherlands: 150,000,000 ns (150 ms)
Moving Forward
System design is a continuous learning journey. Here is how to keep growing:
Read engineering blogs: Uber Engineering, Netflix TechBlog, Discord Engineering, Stripe Blog. Study how real systems evolved.
Build real systems: Create a side project that requires distributed components. Make mistakes, fix them, learn.
Mock interviews: Practice with peers. Use platforms like Pramp or interviewing.io.
Deep-dive one technology per week: Pick a component (Redis, Kafka, Cassandra, Nginx) and study its internals in depth.
Review your own designs: After deploying a system, look back. What would you do differently? What broke? Document the lessons.
Study the classics: The Google File System, MapReduce, Bigtable, Spanner, DynamoDB paper, Amazon's Dynamo. Understanding the "why" behind these architectures transforms your thinking.
Exercise: Your final challenge: Design a global social video platform that combines elements from YouTube (video hosting + streaming), Twitter (follow/news feed), and WhatsApp (real-time messaging). Apply the full 4-step blueprint. Write, draw, and present your design as if it were the final interview — complete with trade-off analysis, failure scenarios, and scaling plan.