wunder beta📘 How do you design a system under constraints?
A functional requirement specifies a behavior the system must produce (e.g., 'given a long URL, return a short alias'). A non-functional requirement (NFR) constrains the quality of that behavior, such as availability, latency, durability, o
What you’ll learn
- Framing the Lab: From Requirements to a Design SpaceTranslate an ambiguous product ask into explicit functional requirements, non-functional requirements, and quantified constraints that bound the design space.Systems design begins not with diagrams but with disciplined requirement-gathering: separating what the system must do (functional) from how well it must do it (non-functional), and turning vague goals into measurable targets. This lesson establishes the case study we will carry through the lab and the vocabulary for stating constraints precisely. Getting this framing right is what prevents over-engineering and lets every later decision be justified against a written target.
- Estimation and Back-of-the-Envelope Capacity PlanningProduce defensible order-of-magnitude estimates of queries per second, storage, and bandwidth from stated assumptions, and use Little's Law to relate latency, throughput, and concurrency.Before committing to any component, a designer estimates the load the system must absorb so that capacity decisions are grounded rather than guessed. This lesson develops back-of-the-envelope methods for QPS, storage, and bandwidth, and introduces Little's Law as the rigorous link between throughput, latency, and the number of in-flight requests. The goal is the correct order of magnitude, since being off by 2x is acceptable but being off by 100x means designing the wrong system.
- The CAP Theorem and Consistency Trade-offsState the CAP theorem precisely, explain the Gilbert and Lynch result, and reason about consistency-versus-availability choices a partition forces on a replicated system.Any system that replicates data across a network must confront the CAP theorem: when a network partition occurs, the system must choose between consistency and availability. This lesson presents the formal result by Gilbert and Lynch, clarifies Brewer's later refinement that the choice only binds during partitions, and connects these ideas to the spectrum of consistency models a designer can offer. Understanding CAP keeps a design honest about what it can and cannot promise when the network misbehaves.
- Scaling Primitives: Load Balancing, Caching, and PartitioningApply the core horizontal-scaling primitives - load balancing, caching, replication, and consistent-hashing partitioning - and justify each against the case study's workload.Scaling a system beyond one machine relies on a small set of well-understood primitives: distributing requests with load balancers, serving hot data from caches, copying data with replication, and splitting data across nodes with partitioning. This lesson explains how each primitive works and introduces consistent hashing as the technique that lets a cluster grow and shrink without remapping nearly all keys. Each choice is tied back to the read-heavy redirection workload so the reasoning, not just the pattern, is clear.
- Reliability: SLOs, Failure, and Resilience PatternsDefine service-level objectives with percentile latency targets and apply resilience patterns - timeouts, retries with backoff, idempotency, and circuit breakers - to contain failures.A design is only as good as its behavior when components fail, so reliability must be specified and engineered, not assumed. This lesson defines SLIs, SLOs, SLAs, and error budgets, explains why tail-latency percentiles beat averages, and presents the resilience patterns that prevent local failures from cascading. These ideas turn 'the system should be reliable' into measurable targets and concrete mechanisms that the case memo can cite.
- Capstone: Building the Systems Design Lab and Case MemoIntegrate the course's concepts into a complete, justified architecture for the case study and produce the deliverable Systems Design Lab artifact and case memo.This final lesson synthesizes requirements, estimation, CAP-aware consistency choices, scaling primitives, and reliability engineering into a single coherent design and the written case memo that defends it. You will assemble the end-to-end architecture for the redirection service, trace a request and a write through it, and structure the memo so every decision cites the requirement and trade-off behind it. The deliverable is a reviewable design artifact, not a finished product, and its quality is measured by the clarity of its reasoning.
Questions this course answers
Which of the following is a non-functional requirement rather than a functional requirement?
Latency and availability targets describe how well a behavior must be performed, making them non-functional requirements. The other three describe behaviors the system must produce, which are functional requirements.
Why does a 100:1 read-to-write ratio matter most when choosing an architecture?
Identifying the dominant access pattern directs design effort where load actually concentrates; a read-heavy ratio favors caching and replication for reads. It neither dictates a specific database nor lets you ignore writes, and it says nothing on its own about availability.
What is the purpose of explicitly listing non-goals in a design memo?
Non-goals communicate that certain features were deliberately excluded to conserve complexity budget, helping reviewers distinguish intentional scope decisions from oversights. They do not make features permanently impossible, do not pad the memo, and do not substitute for functional requirements.
A service handles an average of 2,000 requests per second, and each request spends an average of 0.1 seconds in the system. By Little's Law, what is the average number of requests in flight?
Little's Law gives L = λW = 2,000 × 0.1 = 200. The number of in-flight requests is the product of throughput and average time in the system, not throughput alone or a power-of-ten misplacement.
What accuracy standard is appropriate for back-of-the-envelope capacity estimates?
The purpose of these estimates is to establish scale, so the right order of magnitude is the goal and a factor-of-two error is tolerable. Exact precision is neither achievable nor necessary, and arbitrary guessing defeats the purpose of grounding the design.
Which formula correctly expresses an order-of-magnitude bandwidth estimate?
Bandwidth is the data moved per unit time, estimated as the per-request payload multiplied by the request rate. Storage divided by retention gives a write rate, latency times throughput gives concurrency (Little's Law), and servers times replication factor is unrelated to bandwidth.
Grounded in trusted sources
- Google SRE Book, Chapter 4: Service Level Objectives, https://sre.google/sre-book/service-level-objectives/
- Martin Kleppmann, Designing Data-Intensive Applications (O'Reilly, 2017), Chapter 1: Reliable, Scalable, and Maintainable Applications
- John D. C. Little, 'A Proof for the Queuing Formula: L = λW', Operations Research 9(3), 1961, https://pubsonline.informs.org/doi/abs/10.1287/opre.9.3.383
- Little's law, Wikipedia, https://en.wikipedia.org/wiki/Little%27s_law
- Seth Gilbert and Nancy Lynch, 'Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services', ACM SIGACT News 33(2), 2002
- CAP theorem, Wikipedia, https://en.wikipedia.org/wiki/CAP_theorem
Every Wunder lesson is built from real, reputable sources — never invented.
Related courses
Wunder is a personalized learn-anything platform — tell it any topic and it builds a beautiful, fact-checked course in minutes, with narration, a knowledge check, and a college-style University track.
© 2026 Wunder Learning LLC · Terms & Privacy