Voxtera AIVoxtera AI
Technical

System Design Interview Questions

System design interviews test your ability to design large-scale distributed systems. These open-ended questions evaluate architectural thinking, trade-off analysis, and engineering judgment at senior levels.

Practice with AI Feedback — FreeAI Mock Interview

Sample Questions & Strong Answers

1

Design a URL shortener (like bit.ly).

Clarify: billions of URLs, global scale, analytics needed? Components: API layer, URL generation (base62 encoding of a hash or counter), distributed KV store (Redis + persistent DB), CDN for redirect latency. Key decisions: counter vs. hash for URL generation, collision handling, read vs. write optimization.

💡

Pro tip: URL shortener is a classic starter problem — master it. The key insight is it's a read-heavy system (many redirects per created URL) that benefits from caching.

2

Design Twitter's news feed.

Two approaches: fan-out on write (push new tweets to all followers' feeds immediately — fast reads, slow writes for users with many followers) vs. fan-out on read (pull tweets from all followees at read time — slow reads, no write overhead). Twitter uses a hybrid: push for most users, pull for celebrities.

💡

Pro tip: The celebrity problem (pushing to millions of followers) is the core complexity — always address it.

3

Design a distributed key-value store.

Address: consistent hashing for partitioning, replication factor (3 is standard), consistency model (eventual vs. strong — use quorum reads/writes for tunable consistency), vector clocks for conflict resolution, gossip protocol for failure detection, compaction for storage management.

💡

Pro tip: This is Cassandra/DynamoDB territory — knowing how real systems handle these trade-offs is strong evidence of depth.

4

Design a rate limiter.

Algorithms: token bucket (smooth bursts allowed), fixed window counter (simple, edge case at window boundary), sliding window log (accurate, memory-intensive), sliding window counter (approximation, memory-efficient). Storage: Redis for distributed rate limiting with atomic increment. Key decisions: per-user vs. per-IP, hard vs. soft limits.

💡

Pro tip: Always ask: single-server vs. distributed rate limiter? The distributed case adds significant complexity (clock skew, race conditions).

Expert tips

1

Always clarify requirements and constraints before designing — number of users, read/write ratio, latency requirements, consistency needs.

2

Develop a consistent framework: requirements → scale estimation → high-level design → detailed design → bottlenecks → trade-offs.

3

Know the CAP theorem and consistency trade-offs — every distributed system makes these choices.

4

Practice 10–15 canonical system design problems: news feed, URL shortener, ride-sharing, distributed cache, search autocomplete, rate limiter.

Related interview topics

Behavioral QuestionsSTAR MethodLeadership QuestionsSQL Questions

System Design Interview Questions FAQ

Step 1: Clarify functional requirements (what does the system do?). Step 2: Define non-functional requirements (scale, latency, consistency, availability). Step 3: Do back-of-envelope estimation (QPS, storage needs). Step 4: High-level design (components and data flow). Step 5: Deep dive on key components. Step 6: Discuss trade-offs and failure scenarios. Don't start designing before you understand the requirements.

CAP theorem states that a distributed system can only guarantee two of three properties: Consistency (every read sees the most recent write), Availability (every request receives a response), and Partition Tolerance (the system continues operating during network partitions). Since network partitions are inevitable, real systems choose between CP (consistent but may be unavailable during partitions) and AP (available but may return stale data). Examples: HBase, Zookeeper = CP; Cassandra, DynamoDB = AP (tunable).

Consistent hashing is a technique for distributing data across nodes such that adding or removing a node only requires redistributing a small fraction of data (roughly 1/n keys for n nodes), compared to simple modular hashing which requires redistributing nearly all keys. It's used in distributed caches (Memcached, Redis Cluster), distributed databases (Cassandra, DynamoDB), and load balancers.

Use SQL when: data has a well-defined schema, complex queries with JOINs are needed, ACID transactions are required, data relationships are complex, or reporting/analytics are critical. Use NoSQL when: horizontal scalability is required, schema flexibility is needed (document store), simple key-value access patterns dominate (KV store), time-series data (time-series DB), or graph relationships are central (graph DB). Many modern architectures use both.

Practice System Design Interview Questions with real-time AI.

Stop reading sample answers and start practicing. Get personalized feedback on structure, delivery, and depth — every time.

Start Free PracticeAI Mock Interview

Free plan available · No credit card needed · Cancel anytime