System Design Fundamentals of System Design Syllabus

Fundamentals of System Design syllabus — full chapter and topic list

Expand any chapter to see its topics and sub-topics. This is the whole examinable outline for Fundamentals of System Design in System Design, not a summary of it.

1. 1

   Performance Metrics and Non-Functional Requirements

   4 topics

   • Latency vs Throughput
   • Availability and the Nines
   • Reliability and Fault Tolerance
   • Scalability, Maintainability, and Durability
2. 2

   Scaling Strategies

   4 topics

   • Vertical Scaling (Scale Up)
   • Horizontal Scaling (Scale Out)
   • Stateless vs Stateful Services
   • Capacity Estimation and Back-of-the-Envelope Calculation
3. 3

   The CAP and PACELC Theorems

   3 topics

   • Consistency, Availability, Partition Tolerance
   • Trade-offs in Distributed Systems
   • PACELC Extension
4. 4

   Consistency Models

   4 topics

   • Strong Consistency
   • Eventual Consistency
   • Causal and Read-Your-Writes Consistency
   • Quorum-Based Consistency
5. 5

   Networking Foundations

   4 topics

   • TCP/IP and UDP
   • HTTP/HTTPS and HTTP/2, HTTP/3
   • DNS and Domain Resolution
   • TLS and Public Key Infrastructure

Fundamentals of System Design flashcards for System Design

24 of 50 cards from the Fundamentals of System Design deck — real questions with worked answers.

1. Define latency and throughput, and explain how they differ.

   Latency is the time to complete a single operation (e.g., request-to-response), measured in units of time such as $ms$. Throughput is the number of operations completed per unit time (e.g., requests/second). Latency measures delay; throughput measures capacity. They are related but not inverses — a system can have high latency and high throughput simultaneously (e.g., a long pipeline with high concurrency).

2. Why are percentiles (like p99) preferred over averages when measuring latency?

   Averages hide tail behavior; a few very slow requests can be masked by many fast ones. Percentiles describe the distribution: $p50$ (median) is typical experience, while $p99$ means 99% of requests are faster than this value, capturing the slow-tail experience real users hit. Tail latencies matter because a single user request often fans out to many backend calls, so the slowest component dominates.

3. What does 'availability' mean and how is it quantified?

   Availability is the proportion of time a system is operational and able to serve requests. It is quantified as $$A = \frac{\text{Uptime}}{\text{Uptime} + \text{Downtime}}$$ usually expressed as a percentage or in 'nines' (e.g., 99.9%).

4. What is 'the nines' of availability, and how much downtime per year does each level allow?

   'Nines' count the leading 9s in an availability percentage. Approximate annual downtime: two nines ($99\%$) $\approx 3.65$ days; three nines ($99.9\%$) $\approx 8.77$ hours; four nines ($99.99\%$) $\approx 52.6$ minutes; five nines ($99.999\%$) $\approx 5.26$ minutes per year.

5. How do you compute allowed annual downtime from an availability percentage?

   Multiply the fraction of unavailability by the time in a year. With $525{,}600$ minutes per year: $$\text{Downtime} = (1 - A) \times 525{,}600 \text{ min}$$ For example, $A = 99.99\%$ gives $(1 - 0.9999) \times 525{,}600 \approx 52.6$ minutes.

6. How does availability combine for components in series versus in parallel (redundant)?

   For $n$ components in series (all must work), total availability is the product: $A_{series} = \prod_{i=1}^{n} A_i$. For redundant components in parallel (at least one must work), unavailabilities multiply: $A_{parallel} = 1 - \prod_{i=1}^{n}(1 - A_i)$. Series lowers availability; parallel redundancy raises it.

7. Define reliability and distinguish it from availability.

   Reliability is the probability that a system performs correctly without failure over a given period. Availability is the fraction of time it is up. A system can be available but unreliable (up, but returning wrong results), or reliable yet have low availability if repairs take long. Reliability emphasizes correctness over time; availability emphasizes accessibility.

8. What is fault tolerance, and what is the difference between a fault, an error, and a failure?

   Fault tolerance is a system's ability to continue operating correctly despite faults in some components. A fault is a defect or deviation in a component; an error is an incorrect internal state caused by a fault; a failure is when the system deviates from its specified behavior visibly to users. Fault tolerance stops faults/errors from becoming failures, often via redundancy.

9. Define MTBF, MTTR, and how they relate to availability.

   MTBF (Mean Time Between Failures) is average operational time between failures; MTTR (Mean Time To Repair) is average time to recover. Availability is $$A = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}}$$ Higher MTBF and lower MTTR both increase availability.

10. What is durability in the context of storage systems?

    Durability is the guarantee that once data is committed/written, it will not be lost — surviving crashes, power loss, and hardware failures. It is often expressed in nines (e.g., '11 nines', $99.999999999\%$, meaning an extremely low probability of losing an object per year), achieved via replication, erasure coding, and write-ahead logs.

11. Define scalability and distinguish vertical from horizontal scaling.

    Scalability is a system's ability to handle increased load by adding resources. Vertical scaling (scale up) adds more power (CPU, RAM) to a single machine. Horizontal scaling (scale out) adds more machines/nodes and distributes load among them. Horizontal scaling generally offers better fault tolerance and near-linear growth; vertical scaling is simpler but bounded by a single machine's limits.

12. What is maintainability, and what three sub-properties commonly define it?

    Maintainability is how easily a system can be operated, understood, and evolved over time. It commonly comprises: operability (easy to keep running smoothly), simplicity (easy to understand, low accidental complexity), and evolvability/extensibility (easy to change and add features).

13. List the main advantages and limits of vertical scaling (scale up).

    Advantages: simplicity (no distributed-systems complexity), no application changes needed, data stays on one node (easier consistency), lower latency for local operations. Limits: a hard ceiling set by the largest available machine, a single point of failure, and cost that grows non-linearly (high-end hardware is disproportionately expensive), plus downtime often required to upgrade.

14. List the main advantages and challenges of horizontal scaling (scale out).

    Advantages: near-unlimited scaling by adding commodity nodes, better fault tolerance/redundancy, and often lower cost per unit of capacity. Challenges: data partitioning and rebalancing, distributed consistency, network overhead and partial failures, load balancing, and greater operational/architectural complexity.

15. What is the difference between a stateless and a stateful service?

    A stateless service keeps no client-session state between requests; each request contains all needed information, so any instance can handle any request. A stateful service retains session/context data across requests, tying a client to specific state (and often a specific instance). Stateless services scale horizontally more easily and fail over trivially; stateful ones need sticky sessions or shared/replicated state.

16. Why are stateless services easier to scale horizontally?

    Because any instance can serve any request, you can add or remove instances freely and place a load balancer in front without sticky sessions. There is no per-instance session data to migrate or replicate, so failover is trivial (a failed node's requests just go elsewhere). State is externalized to shared stores (databases, caches) rather than living in the app tier.

17. How is state typically externalized to keep application servers stateless?

    By moving session and shared state out of the app tier into external stores: databases for durable data, distributed caches (e.g., Redis/Memcached) for sessions, object stores for files, and token-based auth (e.g., JWT) so the client carries identity. The app servers then hold no critical local state and become interchangeable.

18. What is back-of-the-envelope (capacity) estimation and why is it used in system design?

    It is quick, rough calculation using order-of-magnitude approximations to size a system — estimating QPS, storage, bandwidth, memory, and number of servers — before detailed design. It validates feasibility, reveals bottlenecks, and guides architecture choices without needing precise numbers.

19. List the common powers-of-ten and byte-size shortcuts used in capacity estimation.

    Time: 1 day $\approx 86{,}400 \approx 10^{5}$ seconds; 1 month $\approx 2.5 \times 10^{6}$ s. Data sizes: $\text{KB}=10^{3}$, $\text{MB}=10^{6}$, $\text{GB}=10^{9}$, $\text{TB}=10^{12}$, $\text{PB}=10^{15}$ bytes. A char $\approx 1$ byte; these let you convert daily volumes to per-second rates and storage quickly.

20. How do you estimate write QPS from daily traffic, and derive peak QPS?

    Average QPS $= \dfrac{\text{requests per day}}{86{,}400}$. Peak QPS is estimated by multiplying average by a factor (commonly $2\times$ to $10\times$) to account for bursts: $\text{Peak QPS} \approx k \times \text{Average QPS}$. For example, $100$M requests/day gives $\approx 1{,}157$ QPS average, so peak $\approx 2{,}300$–$11{,}000$ QPS.

21. How do you estimate storage needed per year for a stream of writes?

    $$\text{Storage/year} = \text{writes per day} \times \text{bytes per write} \times 365$$ Then multiply by a replication factor if data is replicated. E.g., $1$M writes/day $\times 1\,\text{KB} \times 365 \approx 365\,\text{GB/year}$ before replication.

22. State the CAP theorem and name its three properties.

    CAP theorem: a distributed data store can simultaneously guarantee at most two of three properties — Consistency (every read sees the latest write), Availability (every request gets a non-error response), and Partition tolerance (system keeps working despite network partitions). Since network partitions are unavoidable, real systems must trade off between C and A during a partition.

23. During a network partition, what choice does CAP force, and what are the two resulting system types?

    When a partition occurs, a system must choose between consistency and availability. A CP system rejects/blocks requests that can't be made consistent (sacrificing availability) to avoid stale/conflicting data. An AP system keeps serving requests on both sides (sacrificing consistency), accepting possibly stale data and reconciling later.

24. Give examples of CP versus AP systems.

    CP (favor consistency during partitions): traditional RDBMS with synchronous replication, HBase, MongoDB (default), ZooKeeper, etcd. AP (favor availability during partitions): Cassandra, DynamoDB, Riak, CouchDB. The classification reflects behavior under partition, not absolute categorization.

See more Fundamentals of System Design flashcards →

Planning Fundamentals of System Design for System Design

Fundamentals of System Design (System Design) FAQ