System Design Interview Questions and Answers

A system design interview tests whether you can design a large software system that is scalable, reliable and maintainable, and whether you can explain your choices and their trade-offs. Unlike coding rounds, there is rarely a single correct answer. Interviewers want to see how you think: how you clarify requirements, estimate scale, choose components and handle failure.

This guide starts with a step-by-step framework for any design question, then answers the most frequently asked questions grouped by topic: fundamentals, networking and APIs, databases, caching, distributed systems and estimation. It finishes with a complete worked design of a URL shortener, key points for other popular design problems, common mistakes and tips to stand out. Each answer links to a detailed tutorial if you want to go deeper.

1. How to Approach a System Design Interview

Most system design rounds last 45 to 60 minutes. A clear structure keeps you on track and shows the interviewer an organised thought process:

1. Clarify requirements. Ask what the system must do (functional requirements) and how well it must do it (non-functional requirements: scale, latency, availability, consistency). Agree on what is out of scope.
2. Estimate scale. Calculate rough numbers: daily active users, requests per second, read/write ratio, storage per year, bandwidth. These numbers justify later choices.
3. Define the API. List the main endpoints or operations, with inputs and outputs, such as POST /urls and GET /{code}.
4. Draw the high-level design. Sketch clients, load balancers, services, databases, caches and queues, and walk through how a request flows.
5. Deep dive. Pick the hardest or most interesting parts (often chosen by the interviewer): data model, database choice, sharding, caching, consistency or a specific algorithm.
6. Discuss bottlenecks and trade-offs. Identify single points of failure, what happens under 10x load, how you would monitor the system and what you would improve with more time.

Read System Design Process and Methodologies and Functional vs Non-Functional Requirements for more on these steps.

2. Fundamentals Questions

1. What is system design?

System design is the process of defining the architecture, components, data flow and interfaces of a system to meet its functional and non-functional requirements. It covers how parts such as clients, servers, databases, caches and queues fit together so the system works correctly, scales with demand, stays available during failures and remains maintainable.

2. What is the difference between high-level design (HLD) and low-level design (LLD)?

HLD describes the big picture: major components, how they communicate, data stores and deployment. LLD zooms into individual components: classes, interfaces, database schemas, algorithms and design patterns. HLD answers "which boxes and arrows?"; LLD answers "what code goes inside each box?". See HLD vs LLD.

3. What are functional and non-functional requirements?

Functional requirements describe what the system does, for example "users can upload photos". Non-functional requirements describe how well it does it: performance, scalability, availability, reliability, security and maintainability, for example "99.9% availability" or "page loads under 200 ms".

4. What is the difference between vertical and horizontal scaling?

Vertical scaling (scaling up) adds more CPU, memory or disk to one machine. It is simple but has a hard limit and leaves a single point of failure. Horizontal scaling (scaling out) adds more machines and spreads the load across them. It scales much further and improves availability, but requires load balancing and usually stateless services. See Scalability.

5. What is the difference between latency and throughput?

Latency is how long one request takes, such as 120 ms. Throughput is how many requests the system handles per unit of time, such as 5,000 requests per second. A highway analogy helps: latency is how long one car takes to travel; throughput is how many cars pass per hour. Improving one does not automatically improve the other. Read Latency and Throughput.

6. What does "five nines" availability mean?

Availability is the percentage of time a system is working. Each extra "nine" cuts allowed downtime by ten times:

Higher availability is achieved through redundancy, failover, health checks and avoiding single points of failure. See Availability.

7. What is the difference between stateless and stateful services?

A stateless service keeps no client data in memory between requests; every request carries what is needed, and any instance can serve it. This makes scaling and recovery easy. A stateful service remembers client data between requests, such as a game server or WebSocket server, which makes scaling and failover harder. A common pattern is to keep application servers stateless and push state into databases, caches or tokens. See Stateful vs Stateless.

8. When would you choose microservices over a monolith?

Start with a well-structured monolith for small teams and new products, because it is simpler to build, test and deploy. Consider microservices when many teams need to work and deploy independently, when parts of the system have very different scaling needs, or when failures must be isolated. Microservices add network calls, distributed data and operational complexity, so the benefits must outweigh those costs. See Monolithic vs Microservices.

9. What is a single point of failure and how do you remove it?

A single point of failure (SPOF) is any component whose failure stops the whole system, such as one database server or one load balancer. Remove SPOFs with redundancy (multiple instances), automatic failover, replication across availability zones, and health checks that route traffic away from failed components.

3. Networking and API Questions

10. What happens when you type a URL into a browser?

The browser resolves the domain with DNS to get an IP address, opens a TCP connection (or QUIC for HTTP/3) and performs a TLS handshake, then sends an HTTP request. The request may pass through a CDN, load balancer and reverse proxy before reaching an application server, which may query caches and databases. The response travels back, and the browser renders the page and fetches extra resources. See Client-Server Architecture.

11. What is the difference between HTTP and HTTPS?

HTTPS is HTTP sent inside a TLS-encrypted connection. It provides confidentiality (encryption), integrity (tamper detection) and authentication (the server proves its identity with a certificate). HTTP uses port 80 and sends plain text; HTTPS uses port 443. See HTTP vs HTTPS.

12. REST vs GraphQL vs gRPC: when do you use each?

• REST: resource-based HTTP APIs with JSON. Simple, cacheable and universally supported; the default for public APIs.
• GraphQL: clients request exactly the fields they need from a single endpoint. Useful when many different clients need different shapes of data, but caching and rate limiting are harder.
• gRPC: binary Protocol Buffers over HTTP/2 with generated clients. Fast and strongly typed; ideal for internal service-to-service communication and streaming.

13. WebSockets vs long polling vs Server-Sent Events?

Long polling holds an HTTP request open until data is ready, then the client reconnects; simple but costly per message. Server-Sent Events stream updates from server to client over one HTTP connection; great for one-way notifications. WebSockets keep a full-duplex connection open for messages in both directions; best for chat, games and collaboration. See WebSockets.

14. What is the difference between a forward proxy and a reverse proxy?

A forward proxy acts for clients: it sends their requests to the internet and hides their identity, often used for filtering and outbound control. A reverse proxy acts for servers: it receives incoming requests, hides the backends and provides load balancing, TLS termination, caching and security. See Forward vs Reverse Proxy.

15. What load-balancing algorithms do you know?

Common algorithms are round robin (take turns), weighted round robin (stronger servers get more), least connections (send to the least busy), least response time, IP hash (same client goes to the same server) and consistent hashing (stable mapping when servers change). Layer 4 balancers route by IP and port; layer 7 balancers can route by URL, headers and cookies. See Load Balancing.

16. What is an API gateway?

An API gateway is a single entry point in front of backend services. It handles routing, authentication, rate limiting, request transformation, TLS termination, logging and sometimes response aggregation, so individual services do not repeat this work. See API Gateway.

17. How would you design rate limiting for an API?

Choose an algorithm such as token bucket (allows bursts), leaky bucket (smooth output), fixed window or sliding window. Identify clients by API key, user ID or IP. Store counters in a fast shared store such as Redis so limits apply across all servers, enforce limits at the gateway, return 429 Too Many Requests with a Retry-After header, and set different limits per plan and per endpoint. See API Security Best Practices.

4. Database and Storage Questions

18. SQL or NoSQL: how do you choose?

Choose SQL (relational) databases when data is structured with clear relationships, you need joins, strong consistency and multi-row ACID transactions, such as orders and payments. Choose NoSQL when you need flexible schemas, very high write throughput, simple access patterns at massive scale or specific models (document, key-value, wide-column, graph). Many systems use both.

19. What is the difference between ACID and BASE?

ACID (Atomicity, Consistency, Isolation, Durability) guarantees correct, all-or-nothing transactions. BASE (Basically Available, Soft state, Eventually consistent) favours availability and scale, accepting brief inconsistency between replicas. See ACID vs BASE.

20. What is the CAP theorem?

The CAP theorem states that during a network partition, a distributed system must choose between consistency (every read sees the latest write) and availability (every request gets a response). Since partitions cannot be avoided, the real choice is CP or AP behaviour during a partition. PACELC adds that, even without partitions, systems trade latency against consistency. See CAP Theorem.

21. How does a database index work, and what does it cost?

An index, usually a B+ tree, keeps column values sorted with pointers to rows, so lookups take O(log n) steps instead of scanning the whole table. Indexes speed up reads, ranges and sorting but slow down writes and use extra storage, so they should be created for real query patterns and verified with EXPLAIN. See Database Indexing.

22. What is database replication and why use it?

Replication keeps copies of data on multiple servers for high availability, read scaling, lower latency for distant users and disaster recovery. Types include single-leader, multi-leader and leaderless, with synchronous or asynchronous propagation. The main challenges are replication lag and safe failover. See Database Replication.

23. What is sharding, and how do you choose a shard key?

Sharding splits data by rows across multiple database servers so storage and write capacity can grow beyond one machine. A good shard key has high cardinality, distributes data and traffic evenly, appears in most queries and does not change. For example, user_id for a social app. Watch out for hotspots, cross-shard queries and resharding. See Database Sharding.

24. What is consistent hashing?

Consistent hashing places servers and keys on a hash ring, assigning each key to the next server clockwise. When a server is added or removed, only about 1/N of keys move, unlike hash % N, which moves most keys. Virtual nodes keep the distribution even. It is used in distributed caches, NoSQL databases and load balancers.

25. How would you store large files such as images and videos?

Store the files in object storage (for example an S3-compatible service), and keep only metadata (owner, size, location, permissions) in a database. Serve files through a CDN, upload directly from clients using pre-signed URLs to avoid passing large files through app servers, and process media asynchronously (thumbnails, transcoding) with background workers.

5. Caching and Performance Questions

26. What caching strategies do you know?

• Cache-aside (lazy loading): the app checks the cache, and on a miss reads the database and fills the cache. The most common pattern.
• Read-through: the cache itself loads missing data from the database.
• Write-through: writes go to the cache and the database together, keeping the cache fresh at the cost of write latency.
• Write-behind (write-back): writes go to the cache and are saved to the database later; fast, but data can be lost if the cache fails.
• Write-around: writes go only to the database; the cache fills on later reads.

See Caching.

27. What are common cache eviction policies?

LRU (least recently used) removes items not accessed for the longest time; LFU (least frequently used) removes the least popular; FIFO removes the oldest; and TTL expiry removes items after a set time. LRU with TTL is a sensible default for most applications.

28. How do you keep a cache consistent with the database?

Common approaches: set a TTL so stale data expires; delete (invalidate) the cache entry when the data changes, usually after the database write commits; use write-through for data that must be fresh; or publish change events (for example via change data capture) that update caches. Perfect consistency is hard, so decide how stale each kind of data may be.

29. What is the thundering herd (cache stampede) problem?

When a popular cache entry expires, many requests miss at once and all hit the database together, which can overload it. Solutions include letting only one request rebuild the entry (a lock or "single flight"), serving slightly stale data while refreshing in the background, adding random jitter to TTLs and pre-warming caches for known hot keys.

30. What is a CDN and when should you use one?

A Content Delivery Network is a network of edge servers worldwide that cache and serve content close to users. Use it for static assets (images, scripts, videos), cacheable API responses and large downloads, to reduce latency, offload origin servers and absorb traffic spikes and attacks. See CDN.

6. Distributed Systems Questions

31. Why use a message queue?

A message queue lets services communicate asynchronously: producers add messages and consumers process them at their own pace. It decouples services, absorbs traffic spikes, enables retries and lets slow work (emails, video processing, reports) happen in the background without making users wait.

32. What is the difference between Kafka and RabbitMQ?

Kafka is a distributed, partitioned log: messages are stored durably and can be replayed by many consumer groups, making it ideal for event streaming and very high throughput. RabbitMQ is a traditional message broker with flexible routing, per-message acknowledgements and priorities, great for task queues and complex routing. See Kafka vs RabbitMQ.

33. What is idempotency and why does it matter?

An operation is idempotent if doing it several times has the same effect as doing it once. In distributed systems, retries and duplicate messages are normal, so operations like payments must be idempotent. A common technique is an idempotency key: the client sends a unique key with the request, and the server stores processed keys so a repeated request returns the original result instead of charging twice.

34. How do you handle transactions across microservices?

Avoid distributed two-phase commit where possible, because it is slow and blocks on failure. Use the saga pattern: a sequence of local transactions, each publishing an event or triggering the next step, with compensating actions to undo earlier steps if a later one fails. Combine it with the transactional outbox pattern to publish events reliably. See Saga Pattern.

35. What is eventual consistency? Give an example.

Eventual consistency means replicas may temporarily disagree, but they converge if updates stop. For example, after you like a post, a friend in another region may see the old like count for a second before it updates. It trades immediate consistency for availability and performance.

36. What is a circuit breaker?

A circuit breaker wraps calls to a remote service. If failures exceed a threshold, it "opens" and fails fast for a while instead of waiting on a broken service, then lets a few test requests through ("half-open") to check recovery. It prevents cascading failures and gives struggling services time to recover. See Circuit Breaker.

37. How do distributed systems elect a leader?

Nodes use a consensus algorithm such as Raft or Paxos, or a coordination service such as ZooKeeper or etcd. A candidate needs votes from a majority of nodes, which guarantees at most one leader per term, even during network partitions. The leader sends regular heartbeats; if they stop, a new election starts.

38. How do you generate unique IDs in a distributed system?

Options include UUIDs (simple, no coordination, but large and unordered; time-ordered UUIDv7 helps), Snowflake-style 64-bit IDs combining a timestamp, a machine ID and a sequence number (compact and roughly time-ordered), or a central service that hands out ranges of IDs to each server.

39. How do you monitor a distributed system?

Use the three pillars of observability: metrics (request rate, error rate, latency percentiles, saturation), logs (structured, with correlation IDs) and distributed tracing (following one request across services). Add health checks, dashboards and alerts based on service-level objectives (SLOs).

7. Back-of-the-Envelope Estimation

Interviewers often ask you to estimate traffic and storage. Exact numbers do not matter; reasonable assumptions and clear arithmetic do. Keep these handy values in mind:

Worked example: a URL shortener with 100 million new short links per month and 100 reads for every write.

• Writes per second: 100,000,000 ÷ 2,592,000 seconds ≈ 40 writes/s.
• Reads per second: 40 × 100 = 4,000 reads/s on average; plan for peaks of 2–3x, about 10,000 reads/s.
• Storage: keep links for 5 years: 100 million × 12 × 5 = 6 billion records. At about 500 bytes each: 6 billion × 500 B ≈ 3 TB.
• Short code length: with 62 characters (a–z, A–Z, 0–9), 6 characters give 62⁶ ≈ 56.8 billion codes and 7 give 62⁷ ≈ 3.5 trillion. Either covers 6 billion links; 7 leaves plenty of headroom.
• Cache: about 4,000 × 86,400 ≈ 346 million reads per day. If 20% of links get 80% of the traffic, caching that hot 20% needs at most about 346 million × 0.2 × 500 B ≈ 35 GB, which fits in a small Redis cluster.
• Bandwidth: reads 4,000 × 500 B ≈ 2 MB/s; writes are tiny.

Conclusion: this is a read-heavy system with modest storage, so caching matters far more than write scaling.

8. Worked Example: Design a URL Shortener

Let us apply the framework to one of the most common interview questions.

Step 1: Requirements

• Functional: create a short link for a long URL; redirect a short link to the original URL; optional custom aliases and expiry dates; basic click analytics.
• Non-functional: very low redirect latency, high availability (redirects must keep working), short codes must be unique and hard to guess, read-heavy traffic (100:1).

Step 2: Estimates

From the previous section: about 40 writes/s, 4,000 reads/s (10,000 at peak), 3 TB over five years and a cache of tens of gigabytes.

Step 3: API

POST /api/v1/urls
     body: { "longUrl": "https://example.com/very/long/path", "customAlias": null, "expiresAt": null }
     201 Created -> { "shortUrl": "https://sho.rt/8sud2" }

GET  /{code}
     301 Moved Permanently (or 302 Found), Location: https://example.com/very/long/path
     404 Not Found if the code does not exist or has expired

A 301 redirect lets browsers cache the mapping, reducing load; a 302 sends every click through your servers, which is needed if you want accurate analytics.

Step 4: High-level design

• Create: the app server gets a unique ID from the ID generator, converts it to a Base62 code, stores code → longUrl in the database and returns the short URL.
• Redirect: the app server looks up the code in Redis; on a miss, it reads the database and fills the cache. It returns a redirect and sends a click event to a queue, so analytics never slow down redirects.

Step 5: Deep dive: generating short codes

Three common approaches:

• Hash the long URL (for example MD5) and take the first 7 characters. Simple, but different URLs can collide, so you must check and retry.
• Counter + Base62: generate a unique number (from a distributed ID generator or pre-allocated ranges per server) and encode it in Base62. No collisions, but sequential codes are guessable; shuffle or add a random component if that matters.
• Pre-generated random codes: a background job creates random unused codes and stores them in a pool that servers draw from.

package com.javabytechie.urlshortener;

public final class Base62 {

    private static final String ALPHABET = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
    private static final int BASE = ALPHABET.length();   // 62

    private Base62() { }

    public static String encode(long id) {
        if (id < 0) {
            throw new IllegalArgumentException("id must not be negative");
        }
        if (id == 0) {
            return "0";
        }
        StringBuilder code = new StringBuilder();
        while (id > 0) {
            code.append(ALPHABET.charAt((int) (id % BASE)));
            id /= BASE;
        }
        return code.reverse().toString();
    }

    public static long decode(String code) {
        long id = 0;
        for (char c : code.toCharArray()) {
            int value = ALPHABET.indexOf(c);
            if (value < 0) {
                throw new IllegalArgumentException("Invalid character: " + c);
            }
            id = id * BASE + value;
        }
        return id;
    }

    public static void main(String[] args) {
        long[] ids = {1L, 61L, 62L, 125_000_000L, 3_521_614_606_207L};
        for (long id : ids) {
            String code = encode(id);
            System.out.printf("id %,20d -> short code %-8s -> decoded %,d%n", id, code, decode(code));
        }
    }
}

id                    1 -> short code 1        -> decoded 1
id                   61 -> short code Z        -> decoded 61
id                   62 -> short code 10       -> decoded 62
id          125,000,000 -> short code 8sud2    -> decoded 125,000,000
id    3,521,614,606,207 -> short code ZZZZZZZ  -> decoded 3,521,614,606,207

The last line confirms the estimate: seven Base62 characters can represent more than 3.5 trillion distinct links.

Step 6: Bottlenecks and trade-offs

• Database: a key-value store (or a relational table with the code as primary key) sharded by code handles the simple lookup pattern well; replicate each shard for availability.
• Hot links: a viral link is served from Redis and can be cached at the CDN edge with a 301.
• Abuse: rate-limit link creation, scan destination URLs for malware and phishing, and allow links to be disabled.
• Expiry: store an expiry time and clean up expired links with a background job.
• Availability: run app servers and caches in several zones; redirects can keep working from cache even if the database is briefly unavailable.

9. Popular Design Questions and Key Points

10. Common Mistakes in System Design Interviews

• Jumping straight into a design without clarifying requirements and scale.
• Staying silent: the interviewer can only judge what you say out loud.
• Over-engineering: adding Kafka, microservices and sharding to a system with 1,000 users.
• Ignoring non-functional requirements such as availability, latency and consistency.
• Naming tools without reasons: "I'll use Cassandra" is weak; "Cassandra suits this write-heavy, key-based workload, and we accept eventual consistency for these reads" is strong.
• Forgetting failure: not discussing what happens when a server, database or region goes down.
• Getting lost in one detail and running out of time before covering the whole system.
• Treating it as a test with one right answer instead of a discussion of trade-offs.

11. Tips to Stand Out

• Start simple, make it work, then scale it step by step, explaining why each new component is needed.
• Use numbers from your estimates to justify decisions, such as "4,000 reads per second fits comfortably in a Redis cluster".
• Always state trade-offs: what you gain, what you give up and when you would choose differently.
• Draw clearly: label components and arrows, and walk through the request flow.
• Invite input: "Would you like me to go deeper into the database or the caching layer?"
• Mention operational concerns: monitoring, alerting, deployments, security and cost.
• Practise out loud with a timer and real design questions, and review real-world architectures to build intuition.

12. Summary

• Use a clear framework: clarify requirements, estimate, define the API, design at a high level, deep dive, then discuss bottlenecks and trade-offs.
• Master the fundamentals: scaling, latency and throughput, availability, stateless services and architecture styles.
• Know the core building blocks: load balancers, proxies, API gateways, databases, replication, sharding, caches, CDNs and queues.
• Understand distributed systems concepts: CAP, consistency models, idempotency, sagas, consensus and observability.
• Practise estimation and full designs such as the URL shortener until the process feels natural.

System design interviews reward clear thinking and honest trade-offs more than memorised answers. Open the FAQ tab for answers to common questions about preparing for system design interviews.

Frequently Asked Questions (FAQ)