How System Design Differs from Software Architecture

Picture a design review at a company that is about to launch a food delivery app. Two engineers are at the whiteboard, and both keep saying the word "architecture." One is drawing boxes inside the app: an ordering module, a payments module, a layer that talks to the database. The other is drawing boxes outside the app: a load balancer, a cache, a second copy of the database in another city. After twenty minutes they realize they have been answering two different questions, and neither has been listening to the other.

The engineers are looking at different views of the same product. Both views matter, and naming the current scope makes the discussion easier to follow. In practice, software architecture can include services, infrastructure and deployment decisions as well as code structure. The distinction in this lesson is a teaching aid, not a fixed industry boundary.

Using the restaurant analogy from the previous lesson, one view shows the stations within a kitchen; another shows deliveries and coordination across several locations. In this lesson, call the first the application view and the second the runtime system view. Both are architectural views, and system design uses both.

What you will learn

By the end of this lesson you will be able to:

Explain how software architecture and system design overlap, and distinguish an application view from a runtime system view.
Identify which view makes a design decision easiest to explain, and where another view is also needed.
Describe how a choice in one bucket forces choices in the other.
Avoid the traps that make interviewers and teammates think you have confused the two.

Two plans for the same product

Two complementary views help explain the food delivery example.

Application view. Focus on modules, layers, dependencies and interfaces inside an application. This view helps explain how the ordering code calls payment behavior, where validation lives and which changes can be made without modifying unrelated code. It is one part of software architecture.

Runtime system view. Focus on deployed services, databases, caches, queues and network interactions. This view helps explain request routing, data placement, capacity and failure behavior. System design connects these choices to product requirements and implementation constraints.

A service can appear as one box in a runtime view and as several modules in an application view. Zoom in or out according to the question being answered. Neither view is complete on its own, and neither belongs exclusively to a particular job title.

Terminology note: The Software Engineering Institute describes architecture in terms of a system’s overall structure and behavior, including qualities such as availability and security. Here, “inner” and “outer” describe the scale of a diagram, not the limits of what an architect may design. SEI’s description provides the broader definition.

Decisions in the application view

Architecture exists to keep an application understandable as it grows. A small app can be a single file. A large one cannot, because nobody can hold it in their head. Architecture is the set of decisions that carve it into pieces people can reason about.

The main decisions look like this:

How the code is split up. Most applications are divided into layers, such as one layer that handles what the user sees, one that holds the rules of the business, and one that reads and writes the database. Others are split into modules by topic: users, orders, payments.
Which pieces may depend on which. If every piece can call every other piece, a change anywhere can break anything. Architecture draws the arrows. Engineers call it coupling when two pieces depend on each other tightly, and reducing coupling is much of the job.
Which patterns to follow. A pattern is a well-known way of arranging code that solves a common problem. Model-View-Controller, for example, separates the data, the display, and the logic that connects them, so that changing the screen does not mean rewriting the rules.
What conventions everyone follows. Naming, folder layout, how errors are reported, which libraries are approved. Boring, and enormously valuable at fifty engineers.

Good architecture shows up as speed. New engineers find their way around. Bugs stay local. Tests are easy to write because the pieces have clear edges. Bad architecture shows up as fear: nobody wants to touch the payments code because the last person who did broke checkout.

Organizing code into modules does not by itself provide redundancy or distribute traffic. Those goals also need runtime decisions. Conversely, code structure can affect throughput and recovery: shared mutable state, a serialized critical path or an expensive query may prevent additional servers from helping.

Decisions in the runtime system view

The runtime view makes deployed components and their connections explicit. It asks:

Where each kind of data lives, and how many copies of it exist.
How requests get spread across many servers, and what happens when one of those servers dies.
How separate services talk to each other over a network that sometimes drops messages.
How to answer quickly for users far away from the servers.
How much all of that costs, and which parts are worth paying for.

The diagram below uses an inner application view and an outer runtime view. Read its software architecture label as the application structure shown inside the box, and its system design label as the surrounding deployment shown here. Real architectural work can cover both views.

Scope difference between system design and software architecture

The application is one box in the runtime diagram, but its implementation still constrains the system. A service with in-memory session state behaves differently when scaled from three copies to thirty. Use the outer view to identify the scaling requirement and the inner view to decide where that state should live.

The same product, two sets of decisions

The cleanest way to feel the difference is to take one product and list the questions each plan has to answer. Here is the food delivery app from the opening, split down the middle.

The question	Application view	Runtime system view
How is the ordering code organized?	Split it into layers: screens, business rules, database access, with rules about which layer calls which.
Where do menus, orders, and delivery histories live?		In a database, with copies in a second region so a failure in one does not lose data.
How does the app know who is logged in?	A single sign-in module that every other module goes through, so the check is written once.
How does sign-in stay up if a server dies?		Run several servers behind a load balancer, so the failed one is simply skipped.
Which language and framework do we use?	Pick one stack the team knows and apply it consistently.
How do menu photos load fast in every country?		Put copies on a content delivery network close to the users.
How does the order code talk to the payment code?	Through an internal interface, so payments can change without touching orders.
How does the order service talk to the courier-tracking service?		Over the network, through an API, with a plan for what to do when the call fails.

The left column emphasizes code organization; the right emphasizes deployment and communication. Some decisions need both. Authentication, for example, includes an internal checking interface and a runtime plan for identity-service availability.

Where the two plans meet

A change in one view can force a change in the other. Consider three examples:

Splitting an application into microservices. This starts as an architecture decision: instead of one application, build several small ones, each owning one business area. The moment you make it, a pile of system design work appears. The services now talk over a network, so you need a way for each one to find the others, a gateway to route incoming requests, and a plan for calls that time out. The next two lessons deal with this directly.

A latency target. Suppose the product requires 99 percent of successful requests to finish within 200 milliseconds at the agreed load. Meeting that target may require changes inside the application as well as the deployment: fewer serial database calls, bounded work per request and caching where its freshness rules are acceptable.

Splitting a database into pieces. Sharding distributes records across storage partitions. The application needs a reliable route to the correct partition, whether that routing lives in its code, a client library or a database service. The Storage, Databases, Replication, and Partitioning section develops this decision in more detail.

The lesson here is that neither plan can be finished alone. Architects need to know what the system around them will demand. System designers need to know what the code can and cannot promise. On healthy teams, the same people hold both plans in their heads and switch between them on purpose.

Interview tip: Interviewers listen for which plan you are talking about. If they ask you to design a system and you spend ten minutes on how you would organize the classes, you have answered an architecture question they did not ask. Say which level you are working at, then stay there until you choose to move.

Common traps

Leaving the scope unstated. A discussion about module dependencies and a discussion about deployment can both be architectural. Name the view so the team knows which question is being answered.
Believing good code is enough. Clean code on a single server still goes down when the server does. Scale and resilience are system design problems.
Believing servers can fix bad code. Throwing more machines at a slow, tangled application buys time, not a fix. Some problems, like a request that makes forty database calls, have to be solved inside the code.
Skipping architecture in small services. "It's only a microservice" is how a small service becomes an unmaintainable one. Each service still needs an internal plan.

Knowledge check

The four questions below use the lesson’s simplified labels: software architecture for the application view, and system design for the runtime view. Identify the most relevant view in each example, while remembering that the terms overlap in professional use.

Using this lesson's distinction between internal code structure and infrastructure design, where does placing application replicas behind a load balancer fit best?

Software architecture, because it changes how the application is structured.

System design, because it is about how requests reach the application and what happens when one copy fails.

Neither, because it is an operations task rather than a design decision.

Using this lesson's terminology, a team organizes one application into screens, business rules and database-access layers. Which category best describes these internal dependency rules?

Software architecture, because it decides how code inside one application is split up and which parts may depend on which.

System design, because layers affect how the system scales.

Both equally, because every code decision is also a system decision.

Using this lesson's inner-plan and outer-plan terminology, how do application architecture and system design relate?

They are independent. A team can finish the architecture without knowing anything about the system around it.

Architecture is the inner plan and system design is the outer plan, and a decision in either one can force decisions in the other.

System design is a small part of software architecture that only matters for very large companies.

A company splits its single application into several microservices. Which new piece of work does that decision create?

Rewriting the user interface, because microservices require a new front end.

Nothing new. The services simply run where the old application ran.

System design work such as routing requests to the right service, letting services find each other, and handling network calls that fail.

Key takeaways

An application view describes modules, layers, dependencies and interfaces inside an application.
A runtime view describes deployed components, data placement, communication and failure behavior.
Software architecture can include both views. System design uses them together to meet requirements.
Choices cross the boundary. Splitting into services creates network problems. A latency promise reaches into the code. A split database forces the code to change.
Know which plan you are talking about, say so, and stay there on purpose.

The next lesson, Defining Requirements: What a System Must Do and How Well, provides the criteria for choosing between designs. Describe the required behavior, workload and quality targets before committing to a particular arrangement of components.