System Design Interview Questions and Answers
Scalability, caching, messaging, consistency and architecture trade-offs.
Whether you are preparing for entry-level System Design interview questions for freshers or senior software engineer interview questions addressing concurrency, scalability, and system architecture, this track provides peer-reviewed model answers with syntax walkthroughs, edge cases, and practical interview tips.
1 How do message queues help and what guarantees do they provide? Medium
Queues decouple producers from consumers, absorb traffic spikes, enable retries and fan-out, and improve resilience when a downstream service is slow or down.
Delivery semantics: at-most-once (may lose), at-least-once (may duplicate, the common default), exactly-once (usually means effectively-once via idempotent processing plus dedupe/deduplication keys). Design consumers to be idempotent.
Patterns: work queues with competing consumers, pub/sub topics, dead-letter queues for poison messages, retry with exponential backoff and jitter, and ordering via partition keys (Kafka) when order matters.
Tools: Kafka for high-throughput, replayable event streams; RabbitMQ/SQS for classic task queues. Discuss backpressure, consumer lag monitoring and schema evolution.
2 What is the difference between SQL and NoSQL and when do you choose each? Medium
SQL (relational): rigid schema, ACID transactions, powerful joins and ad-hoc queries, mature tooling. Excel at structured, relational data with integrity requirements such as finance, inventory and booking systems.
NoSQL families:
- Document (MongoDB): flexible schema, good for evolving content and per-entity aggregates.
- Key-value (Redis, DynamoDB): extremely fast simple lookups, sessions, caches.
- Wide-column (Cassandra, HBase): high write throughput across many nodes.
- Graph (Neo4j): relationship-heavy domains like social or recommendation graphs.
Decision drivers: access patterns, consistency needs, scale shape, query flexibility and team expertise. Many systems are polyglot: a relational core with a search index (Elasticsearch) and a cache (Redis). Avoid choosing NoSQL only to dodge schema design.
3 How would you design a URL shortener like bit.ly? Hard
Requirements: shorten a long URL, redirect quickly, handle ~100M new links per day with a 100:1 read-to-write ratio.
API: POST /api/links {longUrl} -> {shortUrl}; GET /{code} -> 301/302 redirect.
Key generation: base62 encode a global counter, or a distributed ID generator (Snowflake), or a random code with collision retry. Counter-based is compact and collision-free but predictable; random is unguessable but needs a uniqueness check.
Storage: a key-value store (DynamoDB/Cassandra) mapping code -> longUrl, plus a relational table for ownership and analytics. Reads dominate, so cache hot codes in Redis with a high hit rate.
Scale: stateless redirect service behind a load balancer, CDN/edge caching for popular links, read replicas, and async click analytics via a queue (Kafka) so logging never blocks redirects.
Extras: custom aliases, expiry, abuse detection, rate limiting, and 301 (permanent, cacheable) vs 302 (trackable) choice.
4 What is the CAP theorem and how does it guide decisions? Hard
A distributed store can guarantee only two of three during a network partition: Consistency (every read sees the latest write), Availability (every request gets a non-error response) and Partition tolerance (the system keeps working despite dropped messages). Since partitions are unavoidable in real networks, the real choice under partition is consistency vs availability.
- CP systems (HBase, ZooKeeper, etcd) reject requests to stay consistent, good for coordination and financial ledgers.
- AP systems (Cassandra, DynamoDB in some modes, Riak) stay available and reconcile later with eventual consistency, good for shopping carts, feeds and telemetry.
PACELC extends this: even without partitions you trade latency against consistency. Also mention tunable consistency (quorum reads/writes) and that most real systems are a hybrid per operation.
5 Explain caching strategies and common failure modes. Hard
Strategies:
- Cache-aside (lazy loading): app checks cache, on miss reads DB and populates. Most common.
- Read-through: cache library fetches on miss.
- Write-through: write to cache and DB together for consistency.
- Write-behind: write to cache, flush to DB asynchronously for throughput with some durability risk.
Eviction: LRU/LFU/TTL. Place caches at multiple layers: client, CDN, application (Redis/Memcached), and database.
Failure modes:
- Stampede/thundering herd: many requests miss the same key; use locks, single-flight or jittered TTLs.
- Cache penetration: repeated misses for non-existent keys; cache negatives or use a bloom filter.
- Stale data: invalidation is hard; set TTLs, publish invalidation events, or version keys.
- Hot key overload: shard or replicate the key.
Frequently Asked Questions About System Design Interviews
What do hiring managers evaluate in System Design technical rounds?
Technical interviewers look for foundational fluency, idiomatic syntax, clarity when communicating complex logic, and awareness of performance trade-offs (e.g. memory footprint, render performance, and network latency) in production environments.
What are the best interview tips for practicing System Design questions?
Use active recall: summarize each answer in your own words before revealing the model solution. Focus on explaining why a certain approach is chosen rather than just memorizing code syntax.