Skip to content
academia.sh

Course Intermediate

Introduction to System Design

By the end of this course

Start course

01

The Approach

How a system design problem is approached: separating component, contract, and quality decisions, narrowing scope through requirement gathering, functional requirements being separate determinants from non-functional ones, estimating request, data, and bandwidth need with back-of-the-envelope estimation, and communicating a design through diagram, trade-off, and decision rationale.

  1. 01 What Is System Design Breaking a system design down into three kinds of decisions: component boundaries, the contracts that cross them, and the thresholds placed on qualities; separating the three number classes as the answer to where a threshold comes from, and showing that an unclassified number carries no decision.
  2. 02 Approach to the Design Problem Turning a single-line request into a design: separating questions into four families, showing which design step each family blocks, turning an unanswered question into an assumption, and measuring the room scope narrowing opens on the design surface.
  3. 03 Functional and Non-Functional Requirements Showing that the two kinds of requirements are separate determinants: the functional list determining which kind of component is required, thresholds determining how many parts the same work splits into, the change a single threshold produces in the component count when played one at a time, and a threshold's ability to shrink a design.
  4. 04 Back-of-the-Envelope Estimation Gathering twelve assumptions into a single table, and deriving request rate, data growth, and bandwidth need from the table by arithmetic: calculating peak load, finding the load balance behind the cache, a sparse batch job dominating bandwidth, and measuring which result each assumption multiplies by how much.
  5. 05 Communicating the Design Presenting a design in a defensible form: a box-and-arrow diagram whose edge labels are generated from the calculation, a five-field decision record made of scenario, threshold, value, the value's class, and the cost paid, counting missing fields, and screening unmeasured sentences out of the narrative.

02

Fundamental Properties

The metrics that define a system's behavior under load and failure: the independence of latency and throughput, the difference between performance and scalability, the limits of horizontal and vertical scaling, expressing service availability numerically as an outage budget, reading the CAP theorem correctly, the latency trade-off outside a partition, the models between strong and eventual consistency, and active-active versus active-passive failover patterns.

  1. 01 Latency and Throughput Measuring that the two metrics are two independent axes: throughput saturating and latency worsening as concurrency rises, verifying by measurement the relation among concurrency, throughput, and latency, showing the latency cost of approaching saturation with a queueing model, and classifying every number as an assumption, a computed value, or a measurement.
  2. 02 Performance and Scalability Separating two concepts under load: showing that performance is the metric's value at a given load and scalability is how the metric changes with load, measuring two implementations of the end-of-day job at four loads, computing the largest load meeting the threshold as capacity, and separating a constant-factor gain from an order-of-growth gain.
  3. 03 Horizontal and Vertical Scaling The two ways to change a resource and each one's hard limit: measuring the speedup and efficiency of splitting the same job across one to sixteen workers, counting how the partitioning decision changes the serial fraction and the upper bound, measuring the limit that core count places on vertical scaling, and comparing the two paths' cost curves under the same target.
  4. 04 Availability in Numbers Converting a service availability percentage into an outage budget: converting percentages into per-year, per-month, per-week, and per-day duration, splitting the budget between planned work and failure, raising the target making planned work impossible, and computing the effect of multiplication in a series chain and of the complement in replication on composite service availability.
  5. 05 Availability and Consistency Tension Reading the CAP theorem correctly: showing that partition tolerance is not a choice, measuring the answered-request and stale-response counts of the respond and reject policies in the same network partition scenario, calculating the outage budget the reject policy spends and the stale-response count the respond policy produces, and distinguishing the theorem's common misreadings.
  6. 06 PACELC The latency trade-off outside a partition: naming the region where the CAP theorem stays silent, measuring the synchronous-acknowledgment and asynchronous-propagation policies with no partition in terms of the acknowledgment-wait step, messages per write, and the staleness window seen on reads, showing the sensitivity of the arrival-interval and latency assumptions, and classifying a system separately on its two branches.
  7. 07 Consistency Models Separating strong, weak, and eventual consistency: stating that distributed consistency is a different question from transaction isolation, measuring the same event sequence read under three models for the number of times two clients see different values, the number of rounds needed to converge, and the number of monotonic-read violations, and showing that sticky routing fixes monotonic reads while widening the gap between clients.
  8. 08 Availability Patterns Comparing active–active and active–passive failover as patterns: measuring the failover round and the number of requests dropped during it in the same outage scenario, counting the conflicting writes and the lost writes the last-writer-wins rule produces in the active–active setup, converting round counts into requests using the course's assumption table, and showing how key ownership removes the conflict.

Start typing to search.

↑↓ Esc navigate · open · close