CS Fundamentals
System design interview questions on scalability, load balancing, caching, databases, message queues, and designing real-world systems like WhatsApp or Zomato.
How do you approach a system design interview?
Tip: Clarify functional and non-functional requirements (scale, latency, consistency) → estimate capacity (QPS, storage) → define APIs → high-level design → deep-dive into data model, storage, and bottlenecks → address scaling, caching, and failure modes. Drive the conversation and state trade-offs explicitly.
What is horizontal vs vertical scaling?
Tip: Vertical scaling adds more power to one machine — simple but capped and a single point of failure. Horizontal scaling adds more machines behind a load balancer — near-limitless and fault-tolerant, but requires statelessness, data partitioning, and handling distributed-system complexity.
Explain the CAP theorem.
Tip: In a network partition, a distributed system can guarantee only Consistency OR Availability, not both. CP systems (e.g. HBase) reject requests to stay consistent; AP systems (e.g. Cassandra, Dynamo) stay available and reconcile later. Without partitions you can have both — it is a partition-time choice.
What caching strategies and eviction policies do you know?
Tip: Patterns: cache-aside (lazy load), read-through, write-through (consistent, slower writes), write-back (fast, risk of loss). Eviction: LRU, LFU, TTL. Address cache stampede (locking/early refresh) and invalidation — "the hardest problem". Redis/Memcached are common stores.
How would you design a URL shortener like bit.ly?
Tip: Generate a short key via base62 of an auto-increment ID or a hash (handle collisions). Store key→URL in a fast KV store, cache hot URLs, and use a 301/302 redirect on read. Scale reads with caching + replicas; the system is heavily read-dominated. Add analytics asynchronously.
What is a message queue and when do you use one?
Tip: A queue (Kafka, RabbitMQ, SQS) decouples producers from consumers, smooths traffic spikes (buffering), and enables async processing and retries. Use it for background jobs, event-driven pipelines, and to absorb load. Consider ordering, at-least-once delivery, and idempotent consumers.
How do you handle database scaling — replication vs sharding?
Tip: Replication (primary + read replicas) scales reads and adds redundancy but not write capacity, with replication lag. Sharding partitions data across nodes by a shard key to scale writes/storage, but complicates joins, transactions, and rebalancing. Often combine: shard, then replicate each shard.
What is the difference between strong and eventual consistency?
Tip: Strong consistency guarantees every read sees the latest write (needed for bank balances) at the cost of latency/availability. Eventual consistency allows temporary staleness that converges over time (fine for likes, feeds), enabling higher availability and scale. Pick per data criticality.
InterviewEra generates role-specific questions using your actual projects and skills. Get scored feedback on technical depth, clarity, and structure — free to start.