01 — System Design: Breaking a Problem Into Components That Cooperate

"Just drawing boxes on a whiteboard" was how I conflated system design, which made the boxes feel decorative. The framing that finally landed: system design is the iterative process of decomposing a problem into components and specifying how those components cooperate to satisfy a set of stated requirements. [1] The deliverable is the architecture and the component interactions, not a single algorithm.

The part I had to straighten out is that "design" here is not the visual kind. It is a phase of software engineering focused on the _high-level_ structure of a system — what the major pieces are, what each one owns, and what they say to each other [1]. Once I saw it that way, the interview framing stopped being mysterious: a system design round is just "given this problem statement, sketch the components and defend the trade-offs you chose over the alternatives" [2][3].

The recurring loop: problem → components → trade-offs

There is a sequence the roadmap keeps returning to, and treating it as a loop rather than a checklist is what made it stick [2]:

• Understand the problem. Gather the requirements. Who are the users, what do they need, what are the hard constraints (latency budget, uptime target, data volume)?
• Identify scope. Draw the boundary — what the system does and, just as importantly, what it deliberately will not do.
• Look at prior art. Similar systems have been built before. What worked, what failed. Use that to inform decisions rather than reinventing.
• Sketch a high-level design. Main components and the lines between them — a rough architecture diagram or flowchart.
• Refine. Iterate on the details until the design meets the requirements under expected load.
• Document. Future maintainers (including future-me) need to understand _why_, not just _what_.
• Monitor and improve. The design is not done at launch; it evolves with the requirements.

The thing that separates a junior sketch from a defensible design is the trade-off conversation at every step [3]. Every choice — sync vs async, SQL vs NoSQL, one region vs many — closes some doors and opens others. The design is the set of choices and the reasons behind them.

A design is a set of named components and their interactions

Mentally, I now model a system design as a directed graph: nodes are components with a single clear responsibility, edges are the protocols they use to talk.

Each box has one job, and each arrow is a decision — synchronous request/response, a queue, a cache read. The whole point of these notes is to be able to name every box and defend every arrow.

How I use this

When I face a design problem now, I run the loop explicitly: write the requirements and constraints down first, then sketch the components as a graph, then for each arrow ask "why this protocol and not another." The discipline of writing the trade-off next to each choice is what turns a sketch into a design. I also keep the loop running after launch — the design keeps evolving as the requirements do, and pretending it is "done" at deploy is the fastest way to a system that drifts from reality.

References

[1] Swimm, "System design: Complete guide with patterns, examples, and techniques," swimm.io, 2024. [Online]. Available: https://swimm.io/learn/system-design/system-design-complete-guide-with-patterns-examples-and-techniques

[2] D. Martin, "How to approach a system design interview question," system-design-primer (open source), 2024. [Online]. Available: https://github.com/donnemartin/system-design-primer#how-to-approach-a-system-design-interview-question

[3] "My system design template," LeetCode Discuss, 2023. [Online]. Available: https://leetcode.com/discuss/career/229177/My-System-Design-Template

[4] Crio, "A comprehensive guide to system design," crio.do blog, 2024. [Online]. Available: https://www.crio.do/blog/a-comprehensive-guide-to-system-design/

[5] "Intro to architecture and systems design interviews," YouTube, 2023. [Video]. Available: https://www.youtube.com/watch?v=ZgdS0EUmn70