The system design interview evaluates your ability to architect scalable, reliable systems. Unlike coding interviews with a single correct answer, system design interviews assess your reasoning, trade-off analysis, and breadth of architectural knowledge. They are standard for mid-level and senior engineering roles.

This guide gives you a repeatable framework and walks through the concepts and common questions you need to master.

This pairs with the broader technical interview preparation guide and coding interview guide. Before interviews, optimize your resume with the TailorCV ATS score checker and practice with the mock interview tool.

The System Design Framework (Use This Every Time)

Step 1: Clarify Requirements (5 minutes)

Never start designing immediately. Ask questions:

Functional requirements: What features must the system support? Non-functional requirements: How many users? How much data? Read-heavy or write-heavy? Latency requirements? Availability requirements?

Example for a URL shortener: - Functional: shorten a URL, redirect to original, custom aliases, analytics - Non-functional: 100M URLs/day, read:write ratio of 100:1, low-latency redirects

Step 2: Estimate Scale (3 minutes)

Do back-of-envelope calculations: - Requests per second (RPS) - Storage requirements - Bandwidth - Cache size

This shows the interviewer you think about scale concretely.

Step 3: Define the API (3 minutes)

Sketch the core API endpoints: - POST /shorten {long_url} → {short_url} - GET /{short_code} → 302 redirect

Step 4: High-Level Design (10 minutes)

Draw the major components: - Client → Load Balancer → Application Servers → Database - Add caching, CDN, message queues as needed

Step 5: Deep Dive (10 minutes)

Go deep on the most interesting components: - Database schema and choice (SQL vs NoSQL) - How to generate unique short codes - Caching strategy - Handling hot URLs

Step 6: Address Bottlenecks & Trade-offs (5 minutes)

  • What happens at 10x scale?
  • Single points of failure?
  • Consistency vs availability trade-offs?

Core Concepts You Must Understand

Scalability

  • Vertical scaling: bigger machine (limited, single point of failure)
  • Horizontal scaling: more machines (preferred for large scale)

Load Balancing

Distributes traffic across servers. Know round-robin, least-connections, and consistent hashing.

Caching

  • Application cache: Redis, Memcached
  • CDN: caches static content close to users
  • Cache strategies: cache-aside, write-through, write-back
  • Eviction policies: LRU, LFU, TTL

Databases

  • SQL: strong consistency, ACID, relational (PostgreSQL, MySQL)
  • NoSQL: scalability, flexible schema (MongoDB, Cassandra, DynamoDB)
  • Sharding: horizontal partitioning of data
  • Replication: copies for read scaling and failover
  • Indexing: speeds up reads, slows down writes

CAP Theorem

In a distributed system, you can have only 2 of: Consistency, Availability, Partition tolerance. Understand the trade-offs.

Message Queues

Kafka, RabbitMQ, SQS — decouple services, handle async processing, smooth traffic spikes.

Consistency Models

  • Strong consistency: every read gets the latest write
  • Eventual consistency: reads may be stale temporarily, but converge

Walkthrough: Design a URL Shortener

Requirements: Shorten URLs, redirect, 100M new URLs/day, read-heavy.

Scale: 100M writes/day ≈ 1,160 writes/sec. Reads at 100:1 ≈ 116K reads/sec.

API: - POST /shorten → returns short code - GET /{code} → 302 redirect

Short code generation: Base62 encoding of an auto-incrementing ID, or a hash with collision handling. 7 characters of Base62 gives 62^7 ≈ 3.5 trillion URLs.

Database: Key-value store (DynamoDB or Redis) mapping short code → long URL. Read-heavy workload suits a NoSQL store with heavy caching.

Caching: Cache hot URLs in Redis. With 100:1 read ratio, caching dramatically reduces database load.

Scaling: Load balancer + multiple app servers (stateless). Database sharding by short code. CDN for the redirect service.

Walkthrough: Design a Chat System (WhatsApp)

Requirements: 1-on-1 messaging, group chat, online status, message delivery receipts, 500M users.

Key components: - WebSocket connections for real-time messaging - Message queue for delivery - Database for message persistence (Cassandra for write-heavy, time-series messages) - Presence service for online status - Notification service for offline users (push notifications)

Deep dive: How to handle a user who is offline (store and forward), how to deliver to all group members (fan-out), how to scale WebSocket connections (connection servers + a pub/sub layer like Redis).

Common System Design Questions

  • Design a URL shortener (TinyURL)
  • Design a social media feed (Twitter, Instagram)
  • Design a chat application (WhatsApp, Slack)
  • Design a ride-sharing service (Uber, Lyft)
  • Design a video streaming platform (YouTube, Netflix)
  • Design a rate limiter
  • Design a notification system
  • Design a distributed cache
  • Design an e-commerce system (Amazon)
  • Design a search autocomplete system

Common System Design Mistakes

Mistake 1: Jumping to design without clarifying

Always clarify requirements and estimate scale first. Designing before understanding is a red flag.

Mistake 2: Not discussing trade-offs

There is no perfect design. Interviewers want to hear you weigh SQL vs NoSQL, consistency vs availability, etc.

Mistake 3: Staying too high-level

After the high-level design, you must go deep on at least one or two components. Surface-level answers do not demonstrate depth.

Mistake 4: Ignoring bottlenecks

Always discuss what breaks at scale and how you would handle single points of failure.

Conclusion

System design interviews reward structured thinking, scale awareness, and trade-off analysis. Use the 6-step framework every time: clarify, estimate, API, high-level design, deep dive, bottlenecks.

Combine this with the technical interview preparation guide and coding interview guide. Optimize your resume with the TailorCV ATS score checker and practice with the mock interview tool.