System Design Fundamentals Interview Questions and Answers

15 questions on how to approach system design interviews: requirements, estimation, scalability, availability, consistency, and trade-offs.

Published October 24, 2026 · Updated October 29, 2026 · 15 questions

1. 1. How should you approach a system design interview question?

   Work through it in steps and talk while you do. 1) Clarify requirements: functional features and the scale. 2) State non-functional goals: availability, latency, consistency, durability. 3) Estimate traffic and storage. 4) Define the API and data model. 5) Sketch a high-level design. 6) Deep dive into the hardest parts. 7) Discuss bottlenecks, failures, and trade-offs. Ask questions and state assumptions instead of jumping to boxes and arrows.

2. 2. What is the difference between functional and non-functional requirements?

   Functional requirements describe what the system does (users can post messages, search, and follow others). Non-functional requirements describe how well it does it: scalability, availability, latency, consistency, durability, security, and cost. Design decisions are driven mainly by the non-functional ones.

3. 3. What is back-of-the-envelope estimation, and why do it?

   Rough calculations of requests per second, storage, and bandwidth show what scale you are designing for and which parts are likely bottlenecks. Use round numbers and show your work. For example, 100 million requests a day is about 100,000,000 / 86,400, roughly 1,200 requests per second on average, and peaks are often 2 to 10 times higher.

4. 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 a single point of failure. Horizontal scaling (scaling out) adds more machines behind a load balancer, which gives better scalability and fault tolerance but requires stateless services or partitioned data.

5. 5. What does it mean for a service to be stateless, and why does it matter?

   A stateless server keeps no per-user data between requests; any state lives in a shared store such as a database, cache, or token. Any instance can then serve any request, so you can add, remove, and restart instances freely, which makes horizontal scaling and failover simple.

6. 6. What is availability, and what do the 'nines' mean?

   Availability is the share of time a service works. 99.9% (three nines) allows about 8.8 hours of downtime a year, 99.99% about 53 minutes, and 99.999% about 5 minutes. Higher availability needs redundancy, failover, no single points of failure, and careful deployments, and each extra nine costs much more.

7. 7. What is latency versus throughput?

   Latency is how long one request takes. Throughput is how many requests the system handles per unit of time. They are related but different: batching can raise throughput while increasing latency. Report latency with percentiles (p50, p95, p99), because averages hide slow outliers.

8. 8. Explain the CAP theorem.

   In a distributed data store, when a network partition occurs you must choose between consistency (every read sees the latest write) and availability (every request gets a response). Partition tolerance is not optional in a real network. So a system is CP (it refuses some requests to stay consistent) or AP (it keeps answering but may return stale data). PACELC adds that even without partitions there is a trade-off between latency and consistency.

9. 9. What is the difference between strong, eventual, and causal consistency?

   Strong consistency means every read returns the latest committed write, at the cost of coordination and latency. Eventual consistency means replicas converge if no new writes arrive, so reads may be briefly stale, but it scales and stays available. Causal consistency preserves the order of related events, such as seeing a reply only after the post it answers.

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

    A component whose failure takes down the whole system, such as one database server, one load balancer, or one data center. Remove it with redundancy: several instances behind a load balancer, database replicas with automatic failover, multiple availability zones or regions, and health checks that route around failures.

11. 11. What is the difference between REST, GraphQL, and gRPC?

    REST uses resources and standard HTTP verbs, is simple, cacheable, and widely supported. GraphQL lets clients ask for exactly the fields they need in one request, which reduces over- and under-fetching but adds complexity in caching and query cost control. gRPC uses Protocol Buffers over HTTP/2, is compact and fast with strong typing, and suits service-to-service calls.

12. 12. 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. Networks retry requests, so unsafe retries can double-charge a customer or create duplicate orders. Make writes idempotent with idempotency keys (the client sends a unique id and the server remembers the result), and use PUT and DELETE semantics where possible.

13. 13. What is the difference between a monolith and microservices?

    A monolith is one deployable unit: simple to develop, test, and run, but it scales as a whole and can slow a large team down. Microservices split the system into independently deployable services owned by teams, which improves scaling and autonomy at the cost of network calls, distributed data, and operational complexity. Many teams start with a well-structured monolith and extract services when they have a clear need.

14. 14. How do you design for failure?

    Assume everything fails. Use timeouts on every call, retries with exponential backoff and jitter, circuit breakers, bulkheads, graceful degradation (serve cached or partial data), health checks, and rate limits. Replicate data, deploy across zones, and test failures on purpose with chaos experiments and game days.

15. 15. What do you monitor in a production system?

    Use the three pillars: metrics (rates, errors, latency, saturation), logs (structured and searchable), and distributed traces that follow a request across services. Alert on symptoms users feel (error rate, latency, availability against SLOs), not just on machine metrics, and keep dashboards and runbooks for on-call engineers.