System design interview questions
System design rounds test how you think about building something at scale: clarifying requirements, choosing components, and reasoning about trade-offs and failures. There is no single right answer; interviewers judge your process.
The questions below go from the building blocks to full design problems, with what a strong answer should cover.
What interviewers assess
- Clarifying requirements and estimating scale
- Choosing components: databases, caches, queues and load balancers
- Trade-offs: consistency, availability, latency and cost
- Handling failure, monitoring and growth over time
Building blocks questions
When would you choose a SQL database versus a NoSQL database?
What a good answer covers: SQL for relational data, transactions and flexible queries; NoSQL for very high scale, simple access patterns or flexible schemas. Choose by access pattern, not hype.
How does caching improve performance, and what are the risks?
What a good answer covers: Cache-aside, write-through, TTLs and eviction; risks include stale data, cache stampedes and invalidation complexity.
What is the difference between horizontal and vertical scaling?
What a good answer covers: Bigger machines versus more machines; horizontal scaling needs stateless services, load balancing and data partitioning.
Explain the CAP theorem in practical terms.
What a good answer covers: During a network partition you choose between consistency and availability; give real examples where each choice makes sense.
Why use a message queue?
What a good answer covers: Decouple services, absorb traffic spikes and process work asynchronously; mention at-least-once delivery and idempotent consumers.
Intermediate designs questions
Design a URL shortener.
What a good answer covers: Requirements and scale estimates, ID generation (base62 counters or hashes and collisions), storage, a read-heavy cache, redirects, analytics and expiry.
Design a rate limiter for an API.
What a good answer covers: Token bucket or sliding window, where it runs (gateway or service), a shared store such as Redis for distributed limits, and what to return when limited.
Design a notification system (email, SMS, push).
What a good answer covers: An API that accepts requests, queues per channel, retries with back-off, user preferences, templates, deduplication and delivery tracking.
How would you design pagination for a large list API?
What a good answer covers: Cursor-based pagination over offset for large or changing data sets, stable sort keys and consistent results.
Design a file upload service.
What a good answer covers: Pre-signed URLs to object storage, chunked uploads, virus scanning, metadata in a database, CDN delivery and access control.
Advanced designs questions
Design a chat application like WhatsApp or Slack.
What a good answer covers: Persistent connections (websockets), message storage and ordering, delivery and read receipts, offline sync, group fan-out and presence.
Design a news feed.
What a good answer covers: Fan-out on write versus fan-out on read, the celebrity problem, ranking, caching and pagination.
Design a ride-hailing matching system.
What a good answer covers: Location updates at high frequency, geospatial indexing, matching logic, consistency when assigning drivers, and surge handling.
How do you design for failure in a distributed system?
What a good answer covers: Timeouts, retries with back-off, circuit breakers, idempotency, replication, graceful degradation and monitoring.
How would you migrate a monolith to services without downtime?
What a good answer covers: The strangler pattern, carving out by business domain, data ownership, dual writes or change data capture, feature flags and rollback.
Common mistakes
- Drawing boxes before clarifying requirements and scale.
- Naming technologies without justifying them.
- Never mentioning trade-offs or what happens when something fails.
- Going deep on one component and running out of time for the rest.
How to prepare
- Use a repeatable structure: requirements, estimates, API, data model, high-level design, deep dives, failures.
- Practise five classic designs aloud with a timer.
- Revise caching, databases, queues, consistency and load balancing.
- Relate designs to systems you have built and what you would change.
Reading questions only goes so far: the real test is answering them aloud, under follow-up questions. Career Scan builds a mock interview from your own resume and the job, then shows exactly which answers need work.
Frequently asked questions
Are system design interviews only for senior engineers?
They're mainly for mid-level and senior roles. Juniors may get a lighter version focused on basics such as APIs and databases.
How long is a system design interview?
Usually 45 to 60 minutes for one open-ended problem, with the interviewer probing your decisions.
Is there a right answer?
No. Interviewers judge how you clarify the problem, justify trade-offs and adapt when requirements change.