System Design vs Software Architecture vs Software Design
Software architecture is the set of high-level structural decisions that are expensive to change once made. It decides which services exist, where the boundaries between them sit, and which service owns which data. System design is the activity of producing a concrete design for a whole system. It starts from those structural decisions and continues down to the individual parts, the data model, and the flow of data between them. Software design is the detailed design of the code inside one part: its classes, its interfaces, and the design patterns that connect them.
The three terms describe three levels of the same work, not three different jobs. Architecture is the top level. Software design is the bottom level. System design spans both and adds the numbers.
Software Architecture
An architecture decision is one you would not want to reverse after six months of development. Whether to build one large service or many small ones is such a decision. So is which service may write to the orders table, and whether services call each other directly or through a message queue. The typical artifact is a short document with a diagram of the services and a record of why each decision was made.
System Design
System design takes the architecture as a starting point and produces something an engineer could build from. It names the clients, services, databases, caches, and queues, and it states the data model. It then gives each requirement a number: requests per second, a latency target, and an availability target. It also states how the system scales and what happens when a part fails. This is the subject of the system design interview and of the full definition in What is system design in software engineering?.
Software Design
Software design works inside one service or module. It decides the classes and their responsibilities, the interfaces between them, and which design patterns apply. A factory that creates objects and an observer that notifies listeners of a change are two such patterns. The artifact is a class diagram or an interface definition, and the interview that tests it is the object-oriented or low-level design round. The two levels are contrasted in LLD vs HLD.
Comparison Table
| Software architecture | System design | Software design | |
|---|---|---|---|
| Scope | Whole system, structure only | Whole system, every part and flow | One part or module |
| Time horizon | Years; costly to reverse | Months; revised as load grows | Weeks; refactored freely |
| Typical artifacts | Service diagram, decision records | Part diagram, data model, capacity numbers | Class diagram, interfaces |
| Who owns it | Architect or principal engineer | Senior engineer or tech lead | Every engineer on the module |
| Typical interview | Staff-level design discussion | System design round | Object-oriented or low-level design round |
How the Terms Overlap in Practice
The boundaries are not fixed, and the same decision can sit at two levels depending on the company. Choosing a database is architecture at a startup with one team. At a large company where the platform team already made the choice, it is system design. Job postings mix the words for the same reason. A "software architect" posting often describes system design work, and a "senior engineer" posting may expect architecture decisions.
Two rules resolve most of the confusion. First, if a decision would cost more than a few weeks to reverse, treat it as architecture. Second, if a decision affects only the code inside one module, treat it as software design. Everything between those two is system design. System design itself is sometimes divided further, and readers who searched for those categories will find them in What are the 4 types of system design?.
The same boundary question can be asked about coding rather than architecture. Coding produces working functions inside one program, and system design produces the plan those programs run inside. That comparison is in What is the difference between system design and coding?.
What a Design System Is
A design system is a different thing with the two words reversed. It is a shared library of user interface parts, such as buttons, forms, colors, and typography, together with the rules for using them. The goal is that every screen a company ships looks and behaves the same way. Material Design from Google is a well-known example. A design system is owned by designers and front-end engineers and has nothing to do with servers, databases, or scale. When a search for "system design" returns pages about design systems, this reversal of the words is the reason.
How to Prepare
- Practice naming the level. For any decision in a past project, say whether it was architecture, system design, or software design, and why.
- Prepare one example per level. A service boundary you chose, a capacity calculation you did, and a class structure you refactored.
- Train for the system design round. Grokking the System Design Interview works through full designs at the system design level.
- Train for the low-level round separately. Grokking the Object-Oriented Design Interview covers the class-level design that software design interviews test.
GET YOUR FREE
Coding Questions Catalog
$98
$197
$72
