System Design Interview Questions
System design interviews are not about the "right" architecture — they score how you navigate ambiguity: clarify requirements, estimate scale, name trade-offs, and go deep where it matters. The questions below are classics because they force those behaviours.
Q1Design a URL shortener. Everyone says "hash it" — what are the actual hard parts?
What they're checking: Whether you find the real problems inside a deceptively simple prompt.
A strong answer: Collision handling vs pre-generated key ranges, read-heavy caching (reads outnumber writes 100:1), redirect latency, analytics without slowing the hot path, and custom-alias namespace rules.
Q2Design a rate limiter for an API gateway across many nodes.
What they're checking: Distributed state trade-offs at high request rates.
A strong answer: Compare fixed window, sliding log, token bucket; then the distributed question — per-node with sync drift vs centralised Redis with latency vs local-plus-async reconciliation. Say what accuracy you are giving up.
Q3Design the news feed for a social network. Fan-out on write or on read?
What they're checking: The canonical trade-off, and whether you handle the celebrity problem.
A strong answer: Push for normal users (fast reads), pull for high-follower accounts, hybrid at the boundary. Cover ranking as a separate service and feed cache invalidation honestly.
Q4Design a chat system with delivery guarantees. What do "sent", "delivered", "read" actually require?
What they're checking: Message ordering and state machines under network reality.
A strong answer: Client outbox with idempotency keys, server sequencing per conversation, per-message state machine, and multi-device sync — the part most candidates forget until asked.
Q5How would you store and serve 100 million images a day?
What they're checking: Blob storage patterns and CDN literacy.
A strong answer: Object storage with CDN in front, signed URLs for access control, image variants generated async, cache keys with content hashes for infinite TTL. Estimate storage and egress before designing.
Q6Design a distributed job scheduler — cron across a thousand machines.
What they're checking: Exactly-once thinking and failure handling.
A strong answer: Leader election or partitioned ownership for triggering, at-least-once execution with idempotent jobs, missed-run policy, and visibility: every strong answer includes how operators see stuck jobs.
Q7When would you choose SQL vs NoSQL for a new service? Defend with a concrete case.
What they're checking: Whether you pick storage from access patterns or fashion.
A strong answer: Start from queries and consistency needs: relational for transactions and flexible queries; document/KV for known access paths at scale; and note that Postgres handles more than people admit. Defend one real case.
Q8Estimate the infrastructure for streaming video to 10 million concurrent viewers.
What they're checking: Back-of-envelope discipline — numbers before boxes.
A strong answer: Bitrate × viewers → aggregate bandwidth → CDN as the only viable answer → origin offload ratios, then costs. Being within an order of magnitude with clean arithmetic is the win.
Now try answering these under interview pressure
InterviewGPT runs a mock System Design interview — asks questions like these tailored to your situation, listens to your spoken answers, and scores every one with written feedback. First session free, no credit card.
Start a free System Design interview