System design interview basics
How to approach a system design interview when you only have 45 minutes
System design interviews test whether you can design a scalable, reliable system from scratch in 45 minutes. The hardest part isn't knowing the components — it's knowing what to build first. This guide covers the canonical approach (requirements → high-level → deep dive → trade-offs), the most-asked patterns (URL shortener, Twitter, Uber, chat), and the signals interviewers look for.
The 45-minute structure
Minutes 0–5: requirements. Ask clarifying questions. Functional ('do we need read or just write?'), non-functional ('how many users? how much data?'), constraints ('eventual consistency OK?'). Senior interviewers wait for you to ask — junior candidates often skip this and design for the wrong scale. Minutes 5–15: high-level design. Draw the boxes: clients, load balancer, app servers, cache, database, queue, CDN. Talk through the request flow. Minutes 15–35: deep dive. Pick the 1–2 most interesting components and zoom in. Database schema, sharding strategy, replication, cache invalidation. Minutes 35–45: trade-offs and bottlenecks. What breaks at 100x scale? Where would you add a queue? When does eventual consistency stop being acceptable?
Estimation: just do it
Interviewers love when you back-of-envelope. 'If we have 100M DAU and each user reads 10 tweets/day, that's 1B reads/day = ~12k QPS. With a 200KB tweet, that's 2.4GB/sec read bandwidth.' Don't be precise — the point is showing you can reason about scale. Round aggressively: 86,400 seconds/day → 100k.
Common patterns
Read-heavy systems (Twitter feed, news): cache aggressively, fan-out on write or read depending on celebrity follower counts. Write-heavy systems (logging, analytics): use a queue + batch process. Real-time systems (chat, notifications): WebSockets or long-poll, with at-least-once delivery semantics. Geo-distributed systems (Uber, Airbnb): geohash for spatial queries, CRDT for offline writes.
What interviewers actually score
1) Did you ask clarifying questions? 2) Did you arrive at a working high-level design? 3) Can you defend trade-offs (consistency vs latency, complexity vs flexibility)? 4) Do you recognize bottlenecks before being asked? 5) Can you adapt the design when constraints change? You don't need to know every database — you need to reason about choices.
Checklist
- ☐Memorize 4–5 canonical patterns (URL shortener, Twitter feed, chat, ride-sharing, search)
- ☐Practice estimation: rough QPS, bandwidth, storage for 1M / 100M / 1B users
- ☐Know one cache (Redis), one SQL (Postgres), one NoSQL (DynamoDB or Cassandra), one queue (Kafka), one CDN (CloudFront)
- ☐Do 5+ mock system design interviews — the muscle is talking through trade-offs out loud
- ☐On exam day: ask requirements first, draw the boxes second, deep-dive third
How HearQA Helps
- Upload system-design study notes (Designing Data-Intensive Applications, ByteByteGo, Grokking the System Design Interview) and Practice generates fresh problems from them
- Use the Practice → Coding Challenge sub-type for system-design-style problems with rubric grading
- Mock a 45-minute design discussion with HearQA acting as the interviewer asking follow-up questions
FAQ
Do I need to know specific cloud services for system design?
Not specifically. Interviewers care about concepts (load balancer, cache, queue, CDN) more than specific products (ELB, Redis, SQS, CloudFront). Knowing one product per category is enough — you'll never lose points for saying 'a Redis-style cache' instead of naming a specific managed service.
How is system design at FAANG different from other companies?
FAANG interviews skew larger-scale (millions to billions of users) and more focused on trade-offs. Smaller companies often ask the same patterns but tolerate simpler answers. The framework (requirements → design → deep dive → trade-offs) works at both scales — you just dial up or down the estimation rigor.