System Design Interview Guide: From Basics to Advanced

Every system design answer draws from a set of common building blocks. Load balancers distribute traffic across servers (round-robin, least connections, consistent hashing). Caches reduce database load and improve latency (Redis, Memcached). CDNs serve static content from edge locations close to users.

Databases come in two flavors: SQL (PostgreSQL, MySQL) for structured data with ACID guarantees, and NoSQL (MongoDB, Cassandra, DynamoDB) for flexibility, scalability, and specific data models (document, key-value, column-family, graph).

Message queues (Kafka, RabbitMQ, SQS) enable asynchronous processing, decoupling services, and handling traffic spikes. They are essential for event-driven architectures.

API gateways handle authentication, rate limiting, request routing, and protocol translation. They serve as the single entry point for client requests in microservice architectures.

Use this systematic framework for any system design question:

R - Requirements: Clarify functional and non-functional requirements. What features must the system support? What scale (users, requests per second, data volume)? What are the latency, availability, and consistency requirements?

E - Estimation: Do back-of-the-envelope calculations for storage, bandwidth, and QPS. This helps you make informed design decisions. For example: 1 billion users, 10% daily active, 5 requests per user = 500 million daily requests ≈ 6000 QPS.

S - Storage design: Define your data model and choose appropriate databases. Consider read-write ratio, data relationships, consistency needs, and scale requirements.

H - High-level design: Draw the major components and their interactions. Start simple and iterate. Show the flow of a typical request through your system.

A - API design: Define the key APIs your system exposes. This clarifies the contract between components and with clients.

D - Deep dive: Dive into 2-3 critical components. Discuss algorithms, data structures, caching strategies, or consistency mechanisms.

E - Evaluate: Discuss trade-offs, bottlenecks, failure scenarios, and how you would monitor the system.

URL Shortener: Hash generation (Base62, MD5), database design, caching for hot URLs, analytics, and handling collisions. Start simple, then scale to billions of URLs.

Chat Application (WhatsApp): Real-time messaging via WebSocket, message storage and delivery guarantees, read receipts, group chats, media handling, and end-to-end encryption considerations.

Social Media Feed (Twitter/Instagram): Fan-out on write vs fan-out on read for feed generation, ranking algorithms, caching strategies for celebrity users, and media serving through CDN.

Ride Sharing (Uber): Location tracking, matching algorithm, ETA estimation, surge pricing, geospatial indexing (QuadTree, Geohash), and real-time updates.

Video Streaming (Netflix): Video encoding and transcoding, adaptive bitrate streaming, CDN strategy, recommendation engine, and content delivery optimization.

CAP Theorem: In a distributed system, you can only guarantee two of three: Consistency, Availability, Partition Tolerance. Since network partitions are inevitable, the real choice is between CP (strong consistency, may sacrifice availability) and AP (high availability, eventually consistent).

Consistent Hashing: Distributes data across nodes while minimizing redistribution when nodes are added or removed. Essential for cache clusters and distributed databases.

Database Sharding: Horizontal partitioning of data across multiple database instances. Strategies include range-based, hash-based, and geographic sharding. Consider cross-shard queries and rebalancing.

Rate Limiting: Protects services from overload. Algorithms include Token Bucket, Leaky Bucket, Fixed Window, and Sliding Window. Implement at API gateway level for simplicity.

Start by studying 2-3 well-documented system designs thoroughly. Understand every component and why it was chosen. The URL shortener and chat application are excellent starting points.

Then practice designing systems with a 45-minute timer. Draw the architecture, explain your choices, and discuss trade-offs. Record yourself or practice with a friend who can ask challenging questions.

Read engineering blogs from companies like Netflix, Uber, Airbnb, and Stripe. These provide real-world context for how systems are built and evolved at scale.

For each design, practice answering: 'What happens if this component fails?' 'How would you scale this 10x?' 'What are the trade-offs of your approach?' These are common interviewer probes.