What Is System Design?

System design is the practice of turning a fuzzy product requirement — “build something like Twitter” — into a concrete plan: which services exist, where data lives, how requests flow, and what happens when traffic grows 100×.

If you’ve only ever built features inside one codebase, system design is the zoom-out: instead of “how do I write this function?”, the question becomes “how do these twenty machines cooperate so a million people can use this at once?”

Why JavaScript engineers need this

There’s a myth that system design is a backend-Java topic. It isn’t. The moment your Node app outgrows a single process, you’re making system design decisions — whether you do it deliberately or by accident:

• A WebSocket server that holds connections in memory can’t be load-balanced naively.
• An Express route that does heavy work blocks the event loop for every other request.
• A “just cache it” instinct turns into cache invalidation, the second-hardest problem in CS.

This track grounds every concept in the runtime you actually ship on. When we talk about real-time fan-out, we mean socket.io with a Redis adapter. When we talk about background work, we mean BullMQ. When we talk about backpressure, we mean Node streams.

The shape of a system

Almost every system you’ll design is some arrangement of a few repeating pieces: clients, a load balancer, stateless app servers, caches, databases, and async workers fed by a queue. Here’s the canonical skeleton you’ll see again and again:

Every case study in this track — Twitter, YouTube, Gmail, Uber — is a variation on this diagram, with the boxes specialized and the hard parts zoomed in.

Design is just code at a different altitude

The reasoning is the same one you already use when writing functions — you’re just applying it to boxes and arrows instead of variables and calls. Here’s the same “trade memory for speed” decision you make in code, expressed as a cache:

// In code, you memoize to trade memory for speed:
const memo = new Map();
function fib(n) {
  if (n < 2) return n;
  if (memo.has(n)) return memo.get(n);     // cache hit
  const result = fib(n - 1) + fib(n - 2);
  memo.set(n, result);                      // cache fill
  return result;
}

// A Redis cache in front of a database is the SAME idea,
// just across machines instead of within one process.
console.log(fib(40)); // 102334155 — fast, because we cached subproblems

By the end of this track you’ll look at “design Instagram” the way you now look at “reverse a linked list”: a known problem, with known building blocks, and a method for assembling them.

Next up: the repeatable framework for attacking any system design question.