System Design Interview Preparation

# CHAPTER 19

System Design Interview Preparation #

1. Chapter Introduction #

Preparation for a System Design Interview requires a different mindset than LeetCode (Algorithms). You cannot simply memorize code. You must build an architectural vocabulary. This chapter provides the ultimate cheat sheet: the exact Tradeoff matrices you must memorize, a rapid-fire list of the most common interview prompts, and actionable architecture exercises to build your "whiteboard muscle memory."

2. The Ultimate Tradeoff Cheat Sheet #

In an interview, never propose a technology without stating its tradeoff. Memorize these:

1. SQL vs. NoSQL

• *SQL (PostgreSQL):* Pros = Perfect ACID consistency, powerful JOINs. Cons = Difficult to scale horizontally.

• *NoSQL (Cassandra/MongoDB):* Pros = Infinite horizontal scale, flexible schema. Cons = Eventual consistency, complex application-level logic replacing JOINs.

2. Monolith vs. Microservices

• *Monolith:* Pros = Simple deployment, fast in-memory function calls. Cons = Single point of failure, cannot scale individual components.

• *Microservices:* Pros = Independent scaling, fault isolation. Cons = Network latency overhead, distributed transaction nightmares.

3. REST vs. WebSockets

• *REST:* Pros = Easy to cache, native HTTP, stateless. Cons = Client must actively poll for updates.

• *WebSockets:* Pros = Real-time bi-directional push. Cons = Stateful, difficult to scale and load balance.

4. Polling vs. Message Queues (Kafka/RabbitMQ)

• *Synchronous:* Pros = Instant confirmation to the user. Cons = Slow, system crashes if downstream services are offline.

• *Asynchronous (Queues):* Pros = Decouples services, absorbs massive traffic spikes. Cons = User doesn't get instant confirmation, added infrastructure complexity.

3. Top 10 System Design Interview Prompts #

You must practice whiteboarding these 10 classic architectures. They cover 95% of the design patterns you will face.

1. 1. Design a URL Shortener (bit.ly): Tests Base62 encoding, Key-Value stores, and massive Read caching.

1. 2. Design a Chat Application (WhatsApp): Tests WebSockets, Redis Pub/Sub, and Presence servers.

1. 3. Design a Social Media Feed (Twitter/Instagram): Tests Fan-out on Write, Redis timelines, and the Celebrity Edge Case.

1. 4. Design a Video Streaming Platform (Netflix/YouTube): Tests CDNs, Blob Storage (S3), and asynchronous video transcoding queues.

1. 5. Design a Ride-Sharing App (Uber): Tests Geo-spatial indexing (Geohashes) and high-throughput location tracking.

1. 6. Design a Web Crawler (Googlebot): Tests Graph traversal (BFS), URL frontiers, and idempotency.

1. 7. Design a Key-Value Store (Redis clone): Tests Consistent Hashing, Replication, and CAP Theorem internals.

1. 8. Design an E-Commerce Checkout System (Amazon): Tests strict ACID relational databases and distributed transactions (Saga pattern).

1. 9. Design an API Rate Limiter: Tests Token Bucket algorithms and centralized caching at the API Gateway.

1. 10. Design a Collaborative Editor (Google Docs): Tests WebSockets and complex conflict resolution (Operational Transformation).

4. Back-of-the-Envelope Estimation Cheat Sheet #

Interviewers expect you to do rough math. Memorize these standard numbers:

• Bytes: 1 char = 1 Byte. An average text post = 1 KB. An average image = 2 MB. An average video = 50 MB.

• Time: 1 million seconds = 11.5 days.

• Latency Numbers:

• L1 Cache reference: 0.5 nanoseconds

• Main Memory (RAM) read: 100 nanoseconds

• Read 1MB sequentially from SSD: 1 millisecond

• Network round trip (US East to US West): 60 milliseconds

*The Lesson:* RAM is 10,000x faster than reading from a solid-state disk. This is why Caching is mandatory.

5. Time Management and Leadership Signals #

FAANG interviewers look for "Leadership Signals." You earn these by taking control of the interview.

• Drive the Agenda: "I think we have a solid API definition. If you agree, I'd like to move to the High-Level Design."

• Admit Ignorance Gracefully: "I haven't personally configured BGP routing at the network edge, but at the application layer, I would handle regional failover using Route53 Geo-DNS."

• Think Out Loud: Never stare at the board in silence. Even if you are stuck, say, "I am trying to decide between Redis and Memcached here. Redis gives us persistence, but..."

6. Architecture Exercise: "Find the Bottleneck" #

*Exercise:* Look at a simple architecture: Client -> Node.js Server -> PostgreSQL Database. Write down 5 ways this system will break if traffic increases 10,000x. *Answers:*

1. 1. Single server runs out of CPU (Needs Load Balancer + Horizontal Scaling).

1. 2. Database is overwhelmed by Reads (Needs Redis Cache + Read Replicas).

1. 3. Database is overwhelmed by Writes (Needs Master-Slave replication or Sharding).

1. 4. Node.js thread blocked by heavy image processing (Needs SQS Queue + Worker nodes).

1. 5. Global users experience massive latency (Needs a CDN for static assets).

7. Mini Project: The 5-Minute Pitch #

Choose one of the Top 10 Prompts (e.g., URL Shortener). Set a timer for 5 minutes. Practice verbally delivering the Phase 1 (Clarification) and Phase 2 (Estimation) steps out loud. If you stumble, restart. You must have your opening 5 minutes perfectly rehearsed to build immediate confidence.

8. Common Mistakes #

• Buzzword Bingo: Throwing words like "Kafka," "Kubernetes," and "Cassandra" onto the whiteboard without understanding how they actually work. The interviewer will drill into your buzzwords and expose you. Use simpler technologies if you can defend them better.

• Ignoring the Client: Focusing 100% on the backend database and forgetting that Mobile Apps have terrible internet connections and limited batteries. (Mentioning Pagination and GraphQL scores points here).

9. Best Practices #

• Use the Whiteboard Space Wisely: Draw your High-Level architecture large and in the center. Keep APIs and Schema definitions in small text boxes on the far left. Keep a running list of constraints/bottlenecks on the far right.

10. MCQs #

11. Interview Questions #

• Q: "You have a system reading from a MySQL database. Traffic spikes 100x. Walk me through the exact, step-by-step progression of how you scale this database tier." (Hint: Vertical -> Redis -> Read Replicas -> Sharding).

12. FAQs #

• Q: Should I bring my own whiteboard markers?

A: It sounds silly, but yes. In-person interviews often have dry, terrible markers. Bringing your own high-quality markers shows extreme preparation and confidence.

13. Summary #

System Design success relies on mastering the Tradeoff Cheat Sheet. You must be able to instantly articulate the pros and cons of SQL vs. NoSQL, Monoliths vs. Microservices, and REST vs. WebSockets. Practice the Top 10 classic architectures out loud, utilizing the 45-minute time management framework. Treat the interview as a collaborative design meeting, avoid buzzwords you can't defend, and lead the conversation.

14. Next Chapter Recommendation #

You have completed the theoretical and practical preparation. In the final chapter, Chapter 20: Final Projects and Real-World Applications, we will wrap up the course with a massive final project: Architecting an entire E-Commerce system from scratch.