What Is System Design?

Writing a function that turns a long web address into a short code takes an afternoon. Keeping that shortener answering in a few milliseconds for millions of people, while machines crash and traffic spikes, is a different job. That second job is system design.

The rule

Design decides the parts, the paths between them, and the plan for failure.

A system design answers three questions:

• The parts. Which pieces exist? Browsers and apps (clients), application servers that run your code, databases that remember things, and later caches, queues and load balancers.
• The paths. How does a request travel between them, and what data moves along the way?
• The plan for failure. What happens when a part is slow, full, or gone?

Meet Hop, the link shortener we will grow through this whole course. Version one is tiny:

A visitor opens hop.example/x7Kp. The server looks up x7Kp, finds the long address, and replies "go there instead". That is a complete system: parts, a path, and — so far — no plan for failure at all.

Code-level design asks "how should this function be written?" System design zooms out: it asks where each function runs, how many copies run, and what they share. Nobody gets it right once and forever. A design fits a size: what suits a thousand clicks a day is wrong for a billion, and the reverse is just as true.

The shortcut

When you meet any system, draw it as boxes and arrows, then point at each box and ask: "What if this one disappears?"

The trap is designing for a scale you do not have. Hop at a hundred clicks a day does not need twelve services. Good design fits today's size and leaves room for the next one.

Drills

Answer fast — trust the rule.

Remember

• Design decides the parts, the paths between them, and the plan for failure.
• Shortcut: draw boxes and arrows, then ask "what if this one disappears?"
• Trap: designing for a scale you do not have yet.