System Design Interview Questions
MCQ Quiz · All Difficulty Levels
Practice system design interview questions with MCQs covering the architectural concepts and trade-off analysis skills that mid-level and senior engineering roles demand. Topics include scalability patterns (horizontal vs vertical scaling, database sharding and partitioning, consistent hashing), caching strategies (Redis, Memcached, CDN, cache invalidation policies, write-through, write-back, write-around), database selection criteria (SQL vs NoSQL, CAP theorem, eventual vs strong consistency, read replicas), load balancing algorithms (round-robin, least connections, IP hash), message queues and event streaming (Kafka, RabbitMQ, SQS, use cases and trade-offs), microservices vs monolith architecture decisions, API design (REST, GraphQL, gRPC), rate limiting algorithms (token bucket, leaky bucket, sliding window), and high-availability patterns (circuit breakers, bulkheads, idempotency). System design interviews are the primary filter for senior engineering roles, the ability to reason through scalability, reliability, and consistency trade-offs is what separates candidates at this level. Build the frameworks you need to tackle any system design question.
Frequently Asked Questions: System Design Interviews
Common questions developers ask when preparing for System Design technical interviews.
What system design topics are most commonly tested in senior engineering interviews?
Scalability is the central theme: horizontal vs vertical scaling, database sharding, and load balancing strategies. Caching (Redis patterns, cache invalidation, CDN) and database selection (SQL vs NoSQL, CAP theorem trade-offs) come up in nearly every system design round. Designing message queues and event-driven architectures, API design, rate limiting, and high availability patterns (circuit breakers, retries with backoff) are all regularly tested. Interviewers want to see structured thinking and explicit trade-off analysis, not just knowledge of tools.
What is the CAP theorem and how does it apply to database choices?
The CAP theorem states that a distributed system can only guarantee two of three properties simultaneously: Consistency (all nodes return the same, most recent data), Availability (every request receives a response), and Partition tolerance (the system continues operating despite network partitions). Since network partitions are unavoidable in real distributed systems, the practical choice is CP (consistent but may be unavailable during partitions, HBase, Zookeeper) vs AP (available but may return stale data, Cassandra, DynamoDB). Most modern databases offer tunable consistency rather than a hard binary choice.
When should you use SQL vs NoSQL for a new system?
Choose SQL (PostgreSQL, MySQL) when your data has clear relationships and a well-defined schema, when you need ACID transactions (financial data, orders), or when complex ad-hoc queries are required. Choose NoSQL when you need horizontal scalability at massive scale, when your data model is document-like or key-value (user profiles, session data, product catalogs), or when you need flexible schemas for rapidly evolving data structures. Many production systems use both, SQL for transactional data and NoSQL for high-read caches or unstructured data.
How do you approach a system design interview question?
Follow a structured framework: (1) Clarify requirements, ask about scale, users, constraints, and SLAs before designing. (2) Estimate scale, back-of-envelope calculations for QPS, storage, and bandwidth. (3) Propose a high-level architecture, clients, servers, databases, caches. (4) Deep-dive into critical components, the interviewer usually steers you here. (5) Identify and discuss trade-offs explicitly, no design is perfect; interviewers want to see you reason about alternatives. (6) Address failure modes and availability. Breadth first, then depth on what matters.
What is the difference between horizontal and vertical scaling?
Vertical scaling (scaling up) means adding more resources to a single machine, more CPU, RAM, or faster storage. It is simple but has a hard upper limit, creates a single point of failure, and often requires downtime. Horizontal scaling (scaling out) means adding more machines to distribute the load. It has no theoretical upper limit, improves fault tolerance, and is the standard approach for web-scale systems. Horizontal scaling requires that your application be stateless or that state is managed externally (databases, caches, message queues).