# System Design Interview Questions with Answers 12 System Design interview questions, each with a model answer, the points to cover, common mistakes and the follow-ups interviewers ask. _Source: Astra (https://useastra.in). Updated 2026-09-05._ ### 1. How would you design a highly available and scalable URL shortening service like TinyURL or bit.ly from scratch? The design involves a few key components. First, an application server handles two main API endpoints: one for creating a short URL (e.g., POST /shorten) and one for redirection (e.g., GET /{shortHash}). For URL generation, we need a hashing strategy. A popular method is to use a 62-character set (a-z, A-Z, 0-9) and a distributed counter (like Zookeeper or a dedicated database sequence) to generate a unique 6-7 character hash. This avoids collisions. The mapping between the short hash and the original long URL is stored in a highly scalable key-value store, like Redis or DynamoDB, which provides low-latency reads. Reads (redirections) are far more common than writes (creations), so the system must be read-heavy. We'd place a Load Balancer in front of the application servers. For redirection (GET /{shortHash}), the server performs a 301 (permanent) redirect to the long URL found in the database. A Content Delivery Network (CDN) and caching at the application layer (caching popular URLs in Redis) are crucial to reduce latency and database load. **Points a strong answer covers:** - Clarify scale (reads>>writes); short-code generation: base62 counter vs hash - Storage: key->URL table, cache hot links - Redirect via 301/302; availability > consistency; CDN/geo **Common mistakes:** - Jumping to code without requirements/estimates - Ignoring read-heavy ratio **Likely follow-ups:** - 301 vs 302 for analytics -- which and why? - Custom aliases + collisions? **What the interviewer is assessing:** - Canonical warm-up design -- tests structure: requirements -> estimates -> data -> scale. ### 2. Explain the core concepts of the CAP Theorem and provide real-world examples of systems that prioritize different parts of it. The CAP Theorem states that a distributed data store cannot simultaneously guarantee more than two of the following three properties: **C**onsistency (all nodes see the same data at the same time), **A**vailability (every request receives a valid response, even if nodes are down), and **P**artition Tolerance (the system continues to operate despite network failures that split the system into partitions). In modern distributed systems, Partition Tolerance (P) is generally considered non-negotiable. Therefore, designers must choose between Consistency and Availability. **CP (Consistency & Partition Tolerance):** These systems prioritize strong consistency over availability. If a network partition occurs, the system might become unavailable to prevent stale data reads. Examples include financial systems or systems using databases like Google Spanner or CockroachDB. **AP (Availability & Partition Tolerance):** These systems prioritize high availability over strong consistency. During a partition, nodes remain operational, but they might serve stale data. They eventually become consistent once the partition heals. Examples include social media feeds or e-commerce shopping carts, often using databases like Cassandra or DynamoDB. **Points a strong answer covers:** - Partition forces choose: consistency (CP: etcd) vs availability (AP: Dynamo) - Normal operation: latency vs consistency (PACELC) - Per-feature choice, not per-company **Common mistakes:** - "Pick two" myth recital **Likely follow-ups:** - Where in one product would you want both CP and AP subsystems? **What the interviewer is assessing:** - Distributed-trade-off fluency. ### 3. Outline the system design for generating and displaying a user's home timeline or news feed on a social media platform like Twitter. A timeline or news feed system is complex due to the high read-to-write ratio. A common approach is a hybrid model using 'fan-out-on-write' and 'fan-out-on-read'. **Fan-out-on-write (Push):** When a user (e.g., User A) posts a tweet, the system immediately pushes this tweet into the timeline caches (often a Redis list) of all their followers. When a follower opens their app, their timeline is read directly from this pre-computed cache, making it extremely fast. This works well for users with a few thousand followers. **Fan-out-on-read (Pull):** For celebrities with millions of followers, pushing the tweet to every follower's cache is too slow and resource-intensive (a 'hotkey' problem). Instead, when a normal user loads their timeline, the system (1) fetches their pre-computed feed (from non-celebrities) and (2) separately fetches the recent tweets from all the celebrities they follow. It then merges these two lists in real-time to generate the final timeline. This requires services for posting, timeline generation, a social graph database, and extensive caching. **Points a strong answer covers:** - Fan-out on write (precompute timelines) vs on read - Celebrity hybrid; timeline cache (Redis lists) - Ranking layer; pagination; dedupe **Common mistakes:** - Single-strategy answer without the celebrity problem **Likely follow-ups:** - Celebrity posts -- walk the hybrid path - Where does ranking ML slot in? **What the interviewer is assessing:** - The classic feed design -- hybrid reasoning expected. ### 4. What is a Load Balancer, and what are the key differences between Layer 4 (L4) and Layer 7 (L7) load balancing? A load balancer is a critical component that distributes incoming network traffic across a group of backend servers (a server farm) to ensure no single server becomes overwhelmed. This improves application availability, reliability, and performance. The primary differences are in the layer of the OSI model they operate on. **L4 (Transport Layer) Load Balancer:** Operates at the transport layer (TCP/UDP). It makes routing decisions based on information from the first few packets, such as source/destination IP addresses and ports. It does not inspect the content of the packets. Because it's simple, it's extremely fast and has low latency. **L7 (Application Layer) Load Balancer:** Operates at the application layer (HTTP/HTTPS). It can inspect the content of the message (e.g., HTTP headers, URL paths, cookies). This allows for much more intelligent, content-aware routing. For example, it can route requests to `/api/video` to video processing servers and `/api/user` to user management servers, or implement sticky sessions based on user cookies. **Points a strong answer covers:** - Distributes traffic across instances - L4: TCP-level, fast, connection-based - L7: HTTP-aware -- path routing, TLS termination, sticky sessions **Common mistakes:** - No layer distinction **Likely follow-ups:** - When do you need L7 features? - How does LB health-checking interact with deploys? **What the interviewer is assessing:** - Traffic-architecture basics. ### 5. Architect a ride-sharing service like Uber or Lyft, focusing on matching riders with nearby drivers and updating driver locations in real-time. This system is location-intensive. **Driver Location Tracking:** Drivers' apps continuously send their location (latitude, longitude) via a lightweight protocol (like MQTT or WebSockets) to a Location Service. This service updates the driver's location and status (available, on-trip) in a database. To efficiently find nearby drivers, this data is stored in a database optimized for geospatial queries, using techniques like Geohashing or Quadtrees, which partition the map into a grid. **Rider Request (Matching):** When a rider requests a trip, their app sends the request (riderID, location) to a Matching or Dispatch Service. This service queries the Location Service (e.g., 'find all available drivers within a 5km radius of the rider's Geohash'). It then runs an algorithm to select the 'best' driver based on proximity, rating, and other factors. **Trip Management:** Once matched, a Trip Service manages the state of the ride (accepted, en-route, completed). Asynchronous communication via message queues (like Kafka or RabbitMQ) is used heavily to decouple these services (e.g., notifying the driver, updating the rider app, processing payment). **Points a strong answer covers:** - Geo-indexing: geohash/quadtree/H3 for nearby search - Driver location: frequent updates -> in-memory store, batched - Matching service; surge; websockets for live tracking **Common mistakes:** - SQL radius queries at scale - No update-frequency discussion **Likely follow-ups:** - Geohash cell boundaries -- the edge problem? - Location update rate vs freshness trade-off? **What the interviewer is assessing:** - Geo-system design competence. ### 6. Explain the concepts of database sharding and replication, and describe when you would use each technique in a large-scale system. **Replication** is the process of copying data from a primary (master) database server to one or more secondary (replica) database servers. Its primary purpose is to provide **High Availability** and **Fault Tolerance**; if the master server fails, a replica can be promoted to take its place. It also improves **Read Scalability**, as read queries can be distributed across all replica servers, reducing the load on the master (which handles all writes). **Sharding** (or horizontal partitioning) is the process of splitting a single large database table into multiple smaller, more manageable pieces called shards, and distributing them across multiple database servers. Each shard contains a subset of the rows. This is used to achieve **Write Scalability**. When a single server can no longer handle the volume of write traffic or the sheer size of the data, sharding distributes the write load across many servers. You would use **replication** first to handle read-heavy traffic and ensure availability. You would introduce **sharding** when your application's write volume becomes a bottleneck or your dataset grows too large for a single machine. **Points a strong answer covers:** - Replication: copies for availability + read scale - Sharding: split data for write/storage scale - Replicate first; shard when writes/data outgrow one node **Common mistakes:** - Sharding before simpler options **Likely follow-ups:** - Order of scaling steps for a growing DB? **What the interviewer is assessing:** - Scaling-sequence judgment. ### 7. How would you design a distributed cache system like Redis or Memcached? What are the key features and design choices? A distributed cache pools the RAM of multiple servers to act as one large in-memory cache. Key features include: **Fast Lookups:** A key-value store with O(1) average time complexity. **Distribution:** A sharding mechanism is needed to determine which server holds which key. **Consistent Hashing** is the standard algorithm. It maps both servers and keys to a virtual ring. To find a key, you hash it, find its position on the ring, and walk clockwise to the first server you encounter. This minimizes data redistribution when servers are added or removed. **Eviction Policy:** When the cache is full, a policy is needed to remove old data. The most common is **LRU (Least Recently Used)**, where the least recently accessed item is evicted. **Client Library:** A smart client is often used, which holds the consistent hashing ring information and connects directly to the correct server, avoiding a single point of failure. **Failure Handling:** The system must handle node failures. Typically, this means the data on that node is lost, and the application must fetch it from the database (cache-miss). Some systems (like Redis) offer replication for higher availability. **Points a strong answer covers:** - Partitioned in-memory KV; consistent hashing - Eviction: LRU/LFU/TTL; replication for HA - Client vs proxy routing; hot keys **Common mistakes:** - Ignoring eviction/memory bounds **Likely follow-ups:** - Redis cluster vs client-side sharding? - Persistence options and their cost? **What the interviewer is assessing:** - Infrastructure-component internals. ### 8. What is the difference between a SQL (relational) and a NoSQL (non-relational) database? Provide examples of when you would choose one over the other. **SQL Databases** (e.g., PostgreSQL, MySQL) are relational. They store data in structured tables with predefined schemas, enforce relationships between tables, and use SQL (Structured Query Language) for queries. They guarantee **ACID** (Atomicity, Consistency, Isolation, Durability) transactions. **Choose SQL when:** You need strong transactional consistency (e.g., financial systems, e-commerce inventory), your data is highly structured, and you need to perform complex joins and queries. **NoSQL Databases** (e.g., MongoDB, Cassandra, DynamoDB) are non-relational. They come in various types (document, key-value, column-family, graph) and offer flexible schemas, allowing you to store unstructured or semi-structured data. They are designed to scale horizontally and prioritize performance and availability, often providing **BASE** (Basically Available, Soft state, Eventually consistent) guarantees. **Choose NoSQL when:** You have massive datasets that require horizontal scaling (Big Data), your data schema is flexible or evolving rapidly (e.g., user-generated content, IoT data), or you need extremely high write throughput and low latency (e.g., social media feeds, logging). **Points a strong answer covers:** - SQL: relations, joins, ACID, ad-hoc queries - NoSQL: model variety, horizontal scale, flexible schema - Choose by access patterns, consistency, query needs **Common mistakes:** - Hype-based store selection **Likely follow-ups:** - Model a social graph -- which store and why? **What the interviewer is assessing:** - Storage-selection reasoning. ### 9. How would you design a rate limiter for an API to prevent abuse and ensure fair usage among different users? A rate limiter controls the number of requests a user (or IP, or API key) can make in a given time window. **Algorithm Choice:** Common algorithms include **Token Bucket**, **Leaky Bucket**, and **Sliding Window Counter**. The **Sliding Window Counter** is a good hybrid. We use a fast in-memory store like Redis. For each user, we store a count of their requests, timestamped. For a '100 requests per minute' rule, we'd store request counts per second. When a new request comes in, we sum the counts for the last 60 seconds. If the sum is less than 100, we accept the request and increment the counter for the current second. **Architecture:** The rate limiter should be implemented at the edge, either in the **API Gateway** or as a separate middleware. This allows it to reject requests before they hit your core application logic. **Distributed System:** In a distributed environment, all API gateway instances must share the same state. **Redis** is perfect for this, as it provides atomic increment operations (like `INCR`) that prevent race conditions. When a request is rejected, the API should return an **HTTP 429 (Too Many Requests)** status code, and ideally, `Retry-After` headers to inform the client when they can try again. **Points a strong answer covers:** - Token bucket/sliding window; per-user/IP/key - Distributed counters: Redis + Lua atomicity - 429 + Retry-After; gateway placement; burst allowance **Common mistakes:** - Local-only counters behind a LB **Likely follow-ups:** - Sliding window log vs counter accuracy trade-off? **What the interviewer is assessing:** - Correct-under-concurrency design. ### 10. What are microservices, and how do they contrast with a monolithic architecture? Discuss the primary pros and cons of adopting a microservice approach. A **Monolithic** architecture builds an application as a single, unified, and tightly-coupled unit. All components (e.g., UI, business logic, data access) are developed, deployed, and scaled together. **Microservices** structure an application as a collection of small, independent, and loosely-coupled services, each responsible for a specific business capability (e.g., 'user service', 'payment service', 'product service'). **Pros of Microservices:** **Independent Deployment:** Services can be updated and deployed individually without affecting the entire application. **Technology Diversity:** Each service can use the best technology stack for its specific job. **Fault Isolation:** A failure in one service (e.g., 'recommendation service') won't crash the entire application (e.g., 'checkout service'). **Scalability:** Services can be scaled independently (e.g., scale the 'video streaming' service without scaling the 'user login' service). **Cons of Microservices:** **Operational Complexity:** Managing, monitoring, and debugging many moving parts is much harder. **Network Latency:** Services communicate over the network, which is slower than in-process calls in a monolith. **Distributed Data:** Maintaining data consistency across multiple services is challenging, often requiring complex patterns like Sagas. **Points a strong answer covers:** - Micro: independent deploy/scale, team autonomy - Costs: network, data consistency, observability - Monolith-first advice; split on pain **Common mistakes:** - Ignoring the operational platform tax **Likely follow-ups:** - What organizational shape do microservices require (Conway)? **What the interviewer is assessing:** - Architecture-trade-off honesty. ### 11. Design a search autocomplete or typeahead suggestion system, like the one used in the Google search bar, for a large e-commerce website. This system must be extremely fast, providing suggestions in milliseconds. **Data Structure:** The core of this system is a **Trie** (or prefix tree). Each node in the Trie represents a character, and a path from the root to a node forms a prefix. We can store the top 10 most frequent search queries that share that prefix at each node. **Data Source & Ranking:** The Trie is built from historical search query data. Queries are ranked by frequency or popularity. To make suggestions relevant (e.t., 'iPhone 15' is more popular than 'iPhone 3'), we can use a weighted average or decay factor, giving more weight to recent searches. **System Architecture:** 1. **Trie Construction:** A batch job (e.g., a Spark job) runs daily to process search logs, build a new Trie, and rank the suggestions. 2. **Trie Service:** The constructed Trie is loaded into memory on a fleet of dedicated 'Trie Servers'. Since the Trie can be very large, it might be sharded (e.g., by the first character of the prefix). 3. **Application Layer:** When a user types a character, the request hits an application server. This server queries the Trie Service for that prefix (e.g., 'iph'), retrieves the pre-computed list of top suggestions, and returns it. **Caching:** We can heavily cache the results for very common prefixes (e.g., 'i', 'ip', 'iph') in a distributed cache like Redis or at the CDN layer to reduce load on the Trie Servers. **Points a strong answer covers:** - Trie/prefix index; top-K per prefix precomputed - Typo tolerance (edit distance), personalization layer - Latency <100ms: memory + CDN edge; update pipeline offline **Common mistakes:** - DB LIKE queries as the engine **Likely follow-ups:** - How do you refresh trending suggestions hourly at scale? **What the interviewer is assessing:** - Latency-bound design thinking. ### 12. Explain the purpose of a Content Delivery Network (CDN) and how it helps improve the performance and availability of a website. A CDN (Content Delivery Network) is a geographically distributed network of proxy servers. Its primary purpose is to deliver static content (like images, videos, JavaScript files, CSS) to users based on their geographic location. **How it works:** When a user requests a file (e.g., `logo.png`), the request is routed to the nearest CDN 'edge server' instead of the application's origin server. If the edge server has the file cached, it serves it directly, which is very fast. If it's a 'cache miss', the edge server fetches the file from the origin server, caches it for future requests, and then serves it to the user. **Benefits:** 1. **Reduced Latency:** By serving content from a server physically closer to the user, data transfer times are significantly reduced, making the website feel faster. 2. **Reduced Origin Server Load:** The CDN offloads the traffic for static assets, freeing up the origin server's resources (CPU, bandwidth) to focus on dynamic content and business logic. 3. **Higher Availability & Fault Tolerance:** If the origin server goes down, the CDN can often continue to serve the cached content, providing a degree of graceful degradation. 4. **Security:** Many CDNs also provide security features like DDoS mitigation and Web Application Firewalls (WAF). **Points a strong answer covers:** - Edge servers cache static (and some dynamic) content near users - Cuts latency + origin load; availability shield - Invalidation, TTLs, signed URLs; pull vs push **Common mistakes:** - CDN = static-only assumption **Likely follow-ups:** - Cache a personalized page at CDN -- options? **What the interviewer is assessing:** - Edge-architecture literacy. Full topic: https://useastra.in/interview-questions/topic/system-design