System Design in 30 Concepts: The Aerial View

For three lessons you've been on foot. You walked one request through twelve systems, sat at the trade-off table, and grew a marketplace until it demanded shards. Time to climb a hill and look down at the whole territory at once.

Below is system design in thirty concepts — six groups of five. Together they run essentially every large system on Earth: the same thirty ideas, recombined, at Google and at your favorite small startup.

One instruction before you look, and it's the whole lesson: do not memorize this map. That's not humility — it's the design. Every tile is a full lesson somewhere in this curriculum (the badge says which course), taught exactly when you'll need it. Today's job is only orientation: know the territory exists, notice which parts are dark for you, and learn the shape of how it connects.

Scope: each concept below gets one or two plain sentences — the real teaching lives in the lessons named beside them. If a sentence here feels compressed, that's on purpose.

Everything starts with client–server: your device asks, a server answers, and the agreement about how to ask is an API (API Design & REST: Contracts Between Strangers). Two numbers describe every conversation that follows — latency (how fast one answer arrives) and throughput (how many arrive per second) — and they are not the same thing, which is why they share a lesson (Latency vs Throughput vs Bandwidth).

When demand grows you scale up (a bigger machine) or scale out (more machines) — you watched that whole drama in From One User to One Million. How often the system actually answers is availability, measured in nines, where 99.9% quietly means 8.7 hours of silence a year (Availability & the Nines).

And hiding under all of it, the concept L3 taught you the hard way: stateless vs stateful. Servers that remember nothing can be photocopied freely; the moment one remembers your login, it becomes special — and special doesn't scale (Stateful vs Stateless: Where Does State Live?).

Five ideas decide how fast a request feels, and you met every one of them inside your food order.

DNS turns names into addresses — humble, cached everywhere, and capable of making a healthy company vanish when it breaks (DNS: The Internet's Phonebook). A load balancer stands at one address in front of many servers, spreading traffic and silently routing around the dead (Load Balancers: The Traffic Directors). A CDN parks copies of static content near users so images don't commute across oceans — Netflix alone pushes roughly 15% of the world's internet traffic this way (CDNs: Caching at the Edge).

Caching is the same idea generalized: remember recent answers in fast memory so the expensive layer isn't asked the identical question a thousand times (Why Caching Wins — plus four more lessons, because it earns them). And rate limiting is the bouncer: caps on how fast any one client can hit you, protecting against hostiles and — more often — your own buggy retry loops (Rate Limiting: Token Bucket, Leaky Bucket, Windows).

The database row. L3 spoiled the theme: compute photocopies easily; data doesn't.

The first fork is SQL vs NoSQL — strict relational guarantees versus flexible models that trade some guarantees for scale; picking wrong here is among the most expensive mistakes in backend engineering (SQL vs NoSQL: The Decision Rubric). Indexes are sorted shortcuts that make reads fast while quietly taxing every write — and a missing one explains half of all "why is it slow" tickets (Indexes Deep-Dive).

Replication keeps live copies on several machines, for surviving crashes and for serving more readers (Replication Topologies). Sharding goes further and splits the data itself — users A–M here, N–Z there — the last-resort move from the top of the growth staircase (Partitioning vs Sharding). And consistent hashing is the clever pin that holds scaled systems together: add or remove a server and only a sliver of keys has to move (Consistent Hashing — you met its teaser in the caching lessons ahead).

Fast and big is worthless if the answers are wrong. This row is where system design gets genuinely deep — three of these five tiles run all the way into the advanced courses.

ACID transactions make changes all-or-nothing: the crash halfway through a money transfer must never eat the money (ACID, Precisely). Consistency models answer an uncomfortable question replication created: with copies everywhere, how fresh must a read be? There's a whole spectrum between "always newest" and "eventually" (The Consistency Spectrum).

CAP is the famous — and famously misquoted — theorem: when the network partitions, you choose between refusing to answer and risking stale answers (CAP, Properly). Idempotency is the humble property that makes retries safe: the same request twice must equal once — why your double-clicked Pay button didn't charge you twice (Idempotency: Safe to Retry). And consensus — Raft, elections, quorums — is how a cluster of crashing machines still agrees on one truth; it waits for you in course three (Raft, Visually).

How parts of a system talk to each other shapes everything downstream.

Message queues put a buffer between fast producers and steady consumers, turning traffic spikes into quiet backlogs (Message Queues: Absorbing the Burst). Pub/sub flips the pattern: announce "order placed" once, and receipt, loyalty, and dispatch services all hear it without the publisher knowing they exist (Pub/Sub: Broadcasting Events). Between producer and consumer lives an awkward truth called delivery semantics — at-most-once, at-least-once, or the industry's most expensive phrase, exactly-once (Delivery Semantics).

Real-time communication inverts the web's ask-answer rhythm: the server pushes — chat messages, live scores, the driver's dot crawling across your map (WebSockets: The Two-Way Street). And the row's odd one out, microservices vs monolith, is really a communication decision too: one deployable that calls itself, or many small ones that talk over the network — with Segment's famous round trip as the cautionary tale (Microservices — and When to Split, course four).

The last row is the difference between a design on a whiteboard and a system at 3 AM.

Timeouts, retries, and circuit breakers are the reflexes: give up on slow calls, retry safely (see idempotency), and stop calling the dead before one failure cascades into a fleet-wide one — the exact anatomy of AWS's 2020 Kinesis outage (Circuit Breakers, course three). Observability — logs, metrics, traces — is the instrument panel that turns "users say it's broken" into "this service, this line" (The Three Pillars, course four).

SLOs and percentiles replace feelings with numbers: averages lie, p99 tells the truth about your unluckiest users, and an error budget turns "reliable" into something you can spend (SLIs, SLOs & Error Budgets). Batch vs stream decides whether data is processed in nightly piles or as an endless river — your bank statement versus your fraud alert (Batch vs Stream). And auth & TLS guard the doors: who you are, what you may do, and encryption on the wire (AuthN vs AuthZ: Sessions & JWT).

Same thirty concepts, now clickable. For each one: the plain-words meaning, a real-world sighting, and the exact lesson where it's taught in full.

Try this first: don't read them in order. Click the three tiles that feel darkest — the ones you'd least want an interviewer to ask about. That discomfort is data; you'll use it in a minute.

An aerial view purchases orientation and pays in depth — every sentence above compresses a full lesson into a tweet, and compression always lies a little. Two failure modes come with maps like this one:

Treating it as a memorization quiz — thirty flashcards to grind before "really" starting. That's backwards; the map exists so the lessons land in known territory, not the reverse.

And its mirror: term-collecting — learning to say "eventual consistency" without being able to explain why a comment vanishes and reappears. Interviewers are professionally trained to detect exactly this; a term you can name but not explain is worse than one you've never heard.

Used honestly — skim, self-assess, return — a map like this is the cheapest confidence available: nothing in this field will ever again be completely unfamiliar to you.

The self-inventory — ten minutes, genuinely worth it:

1. Go through all thirty tiles in the widget and sort them into three mental buckets: know it (could explain to a junior) · heard of it (could nod along) · new to me.
2. Write down your three darkest tiles — as questions. Not "consensus" but "how do machines agree on anything if any of them can crash mid-sentence?"
3. Find each one's badge and lesson name. That's not trivia — that's your personal reason to reach course two and three.

Check yourself: a typical L1-L3 graduate lands around 9 know / 12 heard / 9 new. If everything felt "known," be suspicious — re-read the term-collecting warning above and try explaining CAP out loud to an empty chair. The chair wins more often than people expect.

• "I should master these 30 before continuing." → Backwards. The curriculum teaches each one exactly when you need it, on foundations you'll have by then. The map is a promise, not a prerequisite.
• "These are 30 separate topics." → They're one system seen from above. Replication creates the consistency problem; queues create delivery semantics; fleets create the stateless requirement. The arrows between tiles are the actual subject of this course.
• "Knowing the term = knowing the thing." → The interview trap. "We'd use consistent hashing here" followed by "...walk me through it" has ended many onsites. The Try-It exercise above is your vaccine.
• "30 concepts = all of system design." → It's the aerial view, not the atlas. This curriculum holds 340+ items; the map is the 30 load-bearing ones every interviewer assumes.
• "The dark tiles mean I'm behind." → The dark tiles are the syllabus working as intended. Nine of thirty were dark for everyone before L1.

• System design runs on ~30 recurring concepts in 6 families — foundations, traffic, data, correctness, communication, and production reality. Same ideas everywhere, endlessly recombined.
• Orientation beats memorization: every tile is a full lesson ahead, with an address. Fear of a term is just a door you haven't opened yet.
• The tiles are connected, not collected — each row creates the next row's problems, which is exactly the order this course walks them.
• Your self-inventory (know / heard / new) is the most honest study plan you own. Revisit this map after each course and watch tiles light up.
• You've already personally met nine of thirty in three lessons — the request journey, the trade-off table, and the growth staircase were this map in disguise.
• Next — How This Course Works + Your Study Plan: turning that inventory into a route (2-week, 6-week, or 3-month) through everything you just saw.