--- title: "01 — System Design: Breaking a Problem Into Components That Cooperate" uid: what-is-system-design tags: ["system-design", "fundamentals", "architecture", "roadmap:system-design"] excerpt: "System design is the iterative process of decomposing a problem into components and specifying how they cooperate to meet stated requirements. The deliverable is architecture, not a single algorithm." date: 2026-08-13T03:27:35+0000 source: https://www.aveshina.my.id/en/blog/what-is-system-design --- "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. ```figure ``` 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](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](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](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/](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](https://www.youtube.com/watch?v=ZgdS0EUmn70) ```quiz Q: System design, as a phase of software engineering, is primarily concerned with… - choosing the right sorting algorithm for a single function - the high-level structure of a system: its architecture and component interactions correct: 1 explain: System design focuses on the high-level design of a software system — the components and how they cooperate — not on individual algorithm micro-optimization. Q: Which of these is NOT a step in the design loop? - Identify scope and what the system will deliberately not do - Document the design and its rationale - Pick the single correct framework to use forever correct: 2 explain: There is no "one correct framework." Design is an iterative loop of understanding the problem, scoping, researching prior art, sketching, refining, documenting, and monitoring. Q: What separates a defensible design from a junior sketch? - the number of boxes in the diagram - explicitly naming the trade-offs behind each choice correct: 1 explain: Every choice closes some doors and opens others. A defensible design records the trade-off and the reasoning, not just the chosen component. Q: The design process is best described as… - a one-time activity completed before launch - an iterative loop that continues to evolve as requirements change correct: 1 explain: The design is not done at launch — it needs continuous monitoring and improvement to meet changing requirements. ```