Skip to main content
CodePeetCodePeet
Fundamentals of System Design

Checkpoint: Core Concepts & Non-Functional Requirements

Introduction

You started this section not sure what "system design" even was. You now carry the working vocabulary of the entire discipline: how systems grow (scaling out, statelessness), how they stay up (availability, reliability, redundancy), how fast and how much they handle (latency, throughput, performance vs scalability), how their data can disagree (consistency), and the hidden costs that dominate the bill (maintainability, simplicity, cost). Nine ideas, one shared truth under all of them: every quality has a price, and good design is choosing which to pay for.

This checkpoint is where that becomes a skill. It is not a vocabulary test — nobody's going to ask you to define "latency." It's nine short product briefs, and for each one you have to make the call a real engineer makes: given this situation, what actually matters, and what's the right move? That's the muscle the whole section was building — and it's exactly what a design review, or an interview, or a 3 a.m. incident, actually demands.

Take it on instinct. Aim for seven of nine on first read. And treat a miss as the most useful thing here: a signpost to the one lesson worth a five-minute revisit before you move on. The taking is the learning.

A recap board for the Core Concepts and Non-Functional Requirements section, laying out its nine mental models as a three-by-three grid of tiles that together form the vocabulary of system design. The tiles: scalability, where you scale out with a stateless fleet rather than just up, because a bigger box has a hard ceiling and is a single point of failure; stateless design, where servers hold no state between requests and push it to a shared store so any server can serve anyone; availability, where 99.9 percent is about 8.8 hours of downtime a year and each additional nine costs about ten times more, with dependencies in series multiplying availability down and redundancy multiplying it back up; reliability and fault tolerance, where failures are inputs to design for and timeouts, circuit breakers, and bulkheads stop a cascade; single points of failure, where you find the one component whose death is fatal and duplicate it across independent failure domains; latency versus throughput versus bandwidth, which are the time of one request, the rate of many, and the width of the pipe, moving on different dials; performance versus scalability, where fast now is not fast at ten times load because performance is a snapshot and scalability is a slope; consistency, where copies of data can disagree and you choose strong or eventual consistency per piece of data; and maintainability, where owning a system costs far more than building it, so you kill accidental complexity and treat every requirement as a budget. A synthesis strip reduces the section to one line: every non-functional requirement costs money, complexity, and time, so you cannot maximize all of them, and good design is triage. Three cards note that the checkpoint tests decisions rather than definitions through nine product-brief scenarios, that taking it is itself the learning with a target of seven of nine, and that the course now steps into how machines actually talk to each other: networking.

See It: Make the Call

Nine scenarios, one per lesson in this section. Read each brief, pick the move you'd actually make, and you'll get an immediate right or wrong, a one-line why, and the lesson it came from. Don't overthink — the goal is to see whether these trade-offs have become instinct yet.

Watch for the trap in every question: there's always an option that's technically true but wrong for the situation — the bigger box, the sticky session, the extra bandwidth, the "just use strong consistency." Spotting which quality matters here is the entire game.

Nine product-brief scenarios, one per lesson in this section — each asks what you'd DECIDE, not what a term means. Pick, get an instant right/wrong with the one-line why and the lesson it came from, and aim for seven of nine on first instinct.

What You Can Now Do

Whatever you scored, step back and notice the size of what you've picked up. Walk into any design conversation and you can now:

  • Choose how to grow — reach for a stateless fleet behind a load balancer instead of a bigger box, and know why (ceiling, cost, single point of failure).
  • Reason about staying up — translate "99.9%" into real downtime, hunt single points of failure, and name the mechanisms (timeouts, circuit breakers, bulkheads, redundancy) that turn a catastrophe into a shrug.
  • Separate speed from volume — tell a latency problem from a throughput problem, and know that bandwidth is neither, and that a fast system isn't automatically a scalable one.
  • Handle data honestly — recognize that copies disagree, and choose strong or eventual consistency per piece of data instead of reaching for one blanket answer.
  • See the whole bill — weigh maintainability, simplicity, and cost, catch premature complexity and compounding tech debt, and treat the non-functional requirements as a budget you allocate, not a wish list you maximize.

That last skill — triage — is the one that separates people who know the words from people who design systems. You just practiced it nine times.

Key Takeaways

The whole section, compressed to what you'll actually reuse:

  • Grow by scaling out — a stateless fleet beats a bigger box (which has a ceiling and is a single point of failure).
  • Availability is math — 99.9% is ~8.8 h/year down; dependencies in series multiply down, redundancy multiplies up — but only if the copies fail independently.
  • Failures are inputs, not surprises — timeouts, circuit breakers, bulkheads, and graceful degradation keep one failure from becoming a system-wide one.
  • Latency, throughput, and bandwidth are three different things — and fast now is not fast at 10× (performance is a snapshot; scalability is the slope).
  • More than one copy of data can disagree — strong vs eventual consistency is a deliberate, per-data choice, forced by physics and the network (the seed of CAP).
  • Owning costs more than building — kill accidental complexity, manage tech debt, and remember the keystone of this whole section:

Every non-functional requirement costs money, complexity, and time. You cannot maximize all of them. Good design is triage — pick the qualities that matter for this system and consciously accept less on the rest.

That's the mindset the rest of this course builds on. So far, though, we've talked about machines mostly as if they were alone or magically connected. It's time to open up the wires between them — how a request actually finds its way from one computer to another across the planet. Next section: Networking — the useful parts.