What is a system design interview?
A system design interview asks you to design a large-scale distributed system within 45 to 60 minutes. Common prompts: design Twitter, design a URL shortener, design Netflix video streaming, design a distributed cache, design a ride-sharing matching system. The interviewer is not expecting a production-ready blueprint. They are evaluating your ability to think through large-scale systems systematically, make and communicate trade-offs, and produce a design that would work at scale.
System design interviews are most common for mid-to-senior software engineering roles (typically E4/L4 and above at big tech). They test practical knowledge of distributed systems components: databases, caches, message queues, load balancers, CDNs, and how they interact. Candidates who have only built small-scale applications and never reasoned about scale struggle with these interviews; preparation requires studying the building blocks explicitly.
How to structure your answer
Use a structured framework to avoid getting lost. Recommended order: 1. Clarify requirements (functional: what must it do? non-functional: scale, latency, consistency requirements). Spend five minutes on this — interviewers sometimes intentionally leave the prompt vague to see if you clarify. 2. Estimate scale (daily active users, requests per second, data size). These numbers drive every subsequent decision. 3. High-level design (components and how they connect). 4. Deep dive on two or three critical components where trade-offs are most important. 5. Identify bottlenecks and discuss solutions.
Trade-offs you must know
SQL vs NoSQL: SQL for structured data with complex queries and strong consistency. NoSQL for high write throughput, flexible schema, or horizontal scaling. Not "NoSQL is better for scale" — it depends on the access patterns. CAP theorem: In a distributed system with network partitions, you choose between Consistency (all nodes see the same data) and Availability (every request receives a response). Most large systems choose availability (AP) with eventual consistency. Read replicas: Separate read and write traffic. Writes go to the primary; reads go to replicas. Trade-off: replication lag means reads may be slightly stale. Caching: Cache-aside, write-through, and write-behind have different consistency and performance characteristics. Know when each is appropriate.
Core building blocks you must know
Learn these well: Load balancers (L4 vs L7, consistent hashing for sticky sessions), CDNs (push vs pull), SQL databases (indexing, sharding strategies, master-slave replication), NoSQL databases (Cassandra for time-series/wide-column, Redis for caching/queues, MongoDB for document), message queues (Kafka for high-throughput event streaming, RabbitMQ for task queues), object storage (S3 for blobs), and search (Elasticsearch for full-text search). For each, know: what problem it solves, its throughput/latency characteristics, and its failure modes.
How to practise system design
Active practice with a partner is more valuable than reading alone. Take a prompt, open a blank whiteboard tool (Excalidraw, Miro), and design the system out loud for 45 minutes. Then compare with reference designs from Grokking System Design, ByteByteGo, or the System Design Primer (GitHub). The gap between what you designed and the reference answer tells you exactly what to study next. Do this weekly for six to eight weeks before a senior engineering interview at a large company.