Complete System Design Interview Guide 2025

System design interviews are the most misunderstood round in software engineering hiring. Candidates spend months grinding algorithm problems but walk into design rounds unprepared, treating them like a trivia quiz instead of a structured conversation about trade-offs.

This guide gives you a complete, battle-tested framework for tackling any system design question - from "design Twitter" to "design a distributed rate limiter" - at companies like Google, Meta, Amazon, Uber, and Flipkart.

Before you start: if you want to practice what you learn here, LLDCanvas's Interview Mode gives you a timed canvas, structured problem briefs, and analytics on your performance across 110+ real LLD and HLD questions.

01Is Your Round HLD or LLD?

This guide covers System Design (HLD) interviews specifically - the round where you architect a full system out of services, data stores, and queues. If your prompt is a single, bounded feature instead - "design a Parking Lot," "design an Elevator," "design an LRU Cache" - you're in an LLD round, and this framework won't be the right tool for it. Start with HLD vs LLD: Key Differences Explained to confirm which one you're facing, then head straight to the LLD Interview Roadmap and 110+ LLD practice problems.

02What Interviewers Actually Evaluate

Most candidates think system design is about knowing the "right" answer. It isn't. There is rarely a single correct architecture - there are architectures with well-understood trade-offs, and interviewers are scoring how you reason about them.

Interviewers evaluate four dimensions:

1. Problem clarification - Do you ask the right questions before jumping to a solution?
2. Structured thinking - Can you break a complex, ambiguous problem into manageable pieces?
3. Technical depth - Do you know why you chose a particular database, queue, or caching strategy, not just its name?
4. Trade-off reasoning - Can you articulate the pros and cons of each decision, including the ones you didn't pick?

A candidate who picks a "suboptimal" architecture but explains the trade-offs clearly will almost always score higher than one who jumps straight to the "correct" answer without reasoning through it.

03The 6-Step Framework

Use this framework as a timer in your head during a 45-60 minute interview. It keeps you from over-indexing on one section and running out of time before you reach trade-offs.

Step 1: Clarify Requirements (~5 minutes)

Never start designing until you understand what you're building. Ask about:

• Functional requirements - what does the system do, and what features are explicitly out of scope?
• Non-functional requirements - expected scale, latency targets, availability, and consistency needs.
• Constraints - is the workload read-heavy or write-heavy? Global or regional? Real-time or batch?

Example, for "design a URL shortener":

• How many URLs are created per day? (100M/day works out to roughly 1,150 writes/second)
• How long does a shortened URL stay valid?
• Do we need click analytics?
• Is 99.9% or 99.99% availability required?

Step 2: Estimate Scale (~3 minutes)

Back-of-the-envelope math signals engineering maturity to the interviewer. Three formulas cover most cases:

• Traffic: QPS = (requests per day) / 86,400
• Storage: (records per day) x (bytes per record) x (retention in years)
• Bandwidth: QPS x (average payload size)

Applied to a URL shortener handling 100M writes/day and 10B reads/day:

• Write QPS: ~1,150/s
• Read QPS: ~115,000/s (a 100:1 read-to-write ratio)
• Storage per URL: ~500 bytes, so 100M x 500B = 50GB/day

Step 3: Define the API (~5 minutes)

Design the public interface before the internals - it forces you to nail down exactly what the system must support.

POST /shorten
Body: { url: "https://very-long-url.com/...", alias?: "my-link", ttl?: 86400 }
Response: { shortUrl: "https://lldcanvas.app/abc123" }

GET /{shortCode}
Response: 301 Redirect to original URL

Step 4: Design the High-Level Architecture (~15 minutes)

Draw the major components and how requests flow through them:

• Client -> Load Balancer -> API Servers -> Database as the request backbone.
• Add a cache (Redis) in front of the database for hot reads.
• Add a CDN for static assets.
• Add a message queue (Kafka) for anything that can be processed asynchronously.

Step 5: Deep Dive into Components (~15 minutes)

Pick 2-3 critical components and go deep rather than skimming everything. For a URL shortener, that means database choice and caching strategy.

• Database choice: this is a key-value access pattern, so a NoSQL store like DynamoDB or Cassandra fits well.
• Short code generation: Base62-encode an auto-incremented ID to produce a compact, collision-free code.
• Caching: keep an LRU cache in Redis for the top 20% of URLs, which typically serve 80% of traffic.
• TTL: match cache TTL to URL expiry so stale entries don't linger.
• Pattern: use cache-aside - check the cache first, and fall back to the database on a miss.

Step 6: Address Trade-offs (~5 minutes)

Close by naming the failure modes and how the system degrades:

• What happens if Redis goes down? The system falls back to the database with a tolerable latency increase.
• What if a single URL goes viral? This is the hot key problem - solve it with a local, in-process cache on each app server.
• CAP theorem applies here: for a URL shortener, choosing availability over strict consistency (AP) is an acceptable trade-off.

04Core Building Blocks to Master

Beyond the framework, most system design questions draw from the same small set of building blocks. Master these once and you can reuse them across dozens of problems.

Databases

Caching Strategies

• Cache-aside (lazy loading): the app checks the cache first; on a miss it loads from the database and populates the cache.
• Write-through: writes go to the cache and database simultaneously - strong consistency, but higher write latency.
• Write-behind (write-back): writes go to the cache only, and get flushed to the database asynchronously - fast writes, but risk of data loss.

Consistent Hashing

Consistent hashing distributes data across nodes in a way that minimizes reshuffling when nodes are added or removed. It's the mechanism behind Redis Cluster, Cassandra's partitioning, and CDN request routing.

CAP Theorem

A distributed system can guarantee at most two of three properties: Consistency, Availability, and Partition Tolerance. Since network partitions are unavoidable in practice, the real choice is between consistency and availability.

• CP systems favor strong consistency and may sacrifice availability during a partition - examples: HBase, ZooKeeper.
• AP systems stay available and may return stale data during a partition - examples: Cassandra, DynamoDB.

Tip: don't just memorize CP vs. AP labels - practice justifying why a specific system (a bank ledger vs. a social feed) should land on one side or the other. That reasoning is what interviewers are actually listening for.

05Common System Design Questions

A handful of questions recur across companies because they each stress a different part of the framework above. Here's how the core ideas map onto three classics.

Design Twitter

• Read-heavy workload, roughly a 100:1 read-to-write ratio.
• Fan-out on write for users with fewer than about 1M followers - push new posts directly into follower timelines.
• Fan-out on read for celebrities - writing to 50M timelines on every post is prohibitively expensive.
• Hybrid approach: celebrity posts are pulled at read time, while regular users' posts are pushed at write time.

Design WhatsApp

• WebSockets maintain persistent connections between clients and servers.
• Message routing flows sender -> WebSocket server -> message queue -> recipient.
• A presence service built on Redis pub/sub tracks online/offline status.
• Message storage favors Cassandra, since the workload is write-heavy and naturally time-ordered.

Design YouTube

• Upload pipeline: raw video -> transcoding -> multiple resolutions -> CDN distribution.
• HLS (HTTP Live Streaming) enables adaptive bitrate playback.
• Video metadata lives in PostgreSQL; the actual video files are stored in S3 or GCS.

Want to work through these end-to-end instead of just reading about them? Practice Design Twitter, WhatsApp, and YouTube on LLDCanvas with a real canvas and structured feedback.

06Conclusion

System design interviews reward structured thinking over encyclopedic knowledge. Master the 6-step framework, understand the core building blocks - databases, caching, consistent hashing, and CAP theorem - deeply enough to derive an architecture rather than recall one, and practice articulating trade-offs on every decision you make.

Do this consistently and a 45-minute design round stops feeling like an interrogation and starts feeling like a conversation you're driving.

Start practicing today with LLDCanvas's Interview Mode - 110+ real problems, timed sessions, and analytics to track your improvement.