System Design Interview Checklist: Framework, Patterns & Key Concepts

System design interviews separate senior engineering candidates from the rest. Unlike coding problems, there is no single correct answer , interviewers want to see structured thinking, explicit trade-off analysis, and awareness of real production constraints. The candidates who do best are not necessarily those with the most experience; they are those with a repeatable framework they apply consistently.

This checklist covers the topics you must know, the framework to structure your answers, and the common patterns interviewers expect you to reach for automatically.

1. The Interview Framework (Use Every Time)

Apply this structure to every system design question, do not dive straight into drawing boxes:

• 1. Clarify requirements (5 min), functional requirements (what the system does) and non-functional requirements (scale, latency, availability, consistency). Ask: How many users? What is the read/write ratio? What SLA is required?
• 2. Estimate scale (2 min), back-of-envelope calculations: queries per second, storage requirements, bandwidth. Write numbers down; interviewers like to see quantified thinking.
• 3. High-level architecture (5 min), clients, load balancer, application servers, databases, caches. Draw the happy path first.
• 4. Deep dive (15 min), go deep on the critical components the interviewer steers you toward.
• 5. Trade-offs and failure modes (5 min), identify bottlenecks, SPOFs (single points of failure), and what happens when components go down.

2. Scalability Patterns (Must Know)

• Horizontal scaling, add more servers behind a load balancer. Requires stateless application tier; state lives in external storage (database, cache, message queue).
• Database sharding, partition data across multiple database nodes. Common strategies: range-based, hash-based, and directory-based. Trade-off: cross-shard queries become complex.
• Read replicas, route read queries to replica nodes, write queries to the primary. Suitable for read-heavy workloads; introduces eventual consistency lag.
• CQRS, Command Query Responsibility Segregation: separate read and write models. Enables independent scaling and optimization of each path.

3. Caching (Critical Topic)

Caching is in almost every system design answer. Know when to use it, what to cache, and the trade-offs of each invalidation strategy.

Cache placement:
  Client-side   → browser cache, mobile app cache
  CDN           → static assets, geographically distributed
  Application   → in-process cache (LRU map in memory)
  Distributed   → Redis, Memcached (shared across servers)
  Database      → query result cache (use sparingly)

Cache invalidation strategies:
  Write-through  → write to cache AND DB synchronously. Consistent, slower writes.
  Write-back     → write to cache; async write to DB. Fast, risk of data loss.
  Write-around   → write to DB only; cache populated on first read (cache-aside).
  TTL expiry     → simplest; eventual consistency; can serve stale data.

4. Database Selection (CAP Theorem in Practice)

Interviewers expect you to justify database choices, not just name a technology. The CAP theorem provides the framework:

• Use SQL (PostgreSQL, MySQL) when you need ACID transactions, complex relational queries, or strong consistency. Suitable for financial data, user accounts, order management.
• Use NoSQL, Document (MongoDB) for flexible schemas, nested data, or rapid iteration. Product catalogs, user profiles, CMS content.
• Use NoSQL, Key-Value (Redis, DynamoDB) for session storage, leaderboards, rate limiting, pub/sub. Redis = in-memory speed; DynamoDB = serverless scale.
• Use NoSQL, Wide Column (Cassandra, HBase) for massive write throughput and time-series data. IoT, analytics, activity feeds.
• Use Search (Elasticsearch) for full-text search, faceted filtering, and log analytics.

5. Key Distributed Systems Concepts to Know

• Consistent hashing, distributes data across nodes and minimizes remapping when nodes are added/removed. Used in CDNs and distributed caches.
• Circuit breaker, stops calling a failing downstream service and fails fast, preventing cascading failures.
• Idempotency, safe to retry an operation without unintended side effects. Critical for payment systems and distributed transactions.
• Rate limiting, token bucket (smooth bursts), leaky bucket (fixed output rate), sliding window (accurate counts). Use Redis for distributed rate limiting.
• Message queues, Kafka for event streaming and durability; RabbitMQ for task queues; SQS for AWS-native serverless workloads.
• Bloom filters, probabilistic membership test; eliminates "definitely not in set" lookups cheaply. Used by Cassandra, BigTable, Chrome safe browsing.

6. System Design Interview Checklist

• ☐ Define functional and non-functional requirements before designing
• ☐ Estimate QPS, storage, and bandwidth with rough numbers
• ☐ Draw a high-level diagram: clients → LB → app servers → storage
• ☐ Address the database: SQL or NoSQL? Why? Read replicas? Sharding?
• ☐ Address caching: where? what strategy? what gets evicted?
• ☐ Address async work: queue or event stream? Kafka or SQS?
• ☐ Address availability: what are the SPOFs? How do you handle failure?
• ☐ Address API design: REST, GraphQL, or gRPC? Rate limiting?
• ☐ State trade-offs explicitly: consistency vs availability, cost vs performance