Software Architecture

The high-level plan for how a software system is organised — what its parts are, how they connect, and the rules that guide decisions about its structure.

What is it?

Every piece of software — from a personal blog to a banking app — is made up of parts that work together. Software architecture is the discipline of deciding what those parts are and how they relate to each other before you start building.

Think of it like designing a building. Before anyone lays a single brick, an architect draws a floor plan: where the rooms go, how hallways connect them, where the plumbing runs. In software, the “floor plan” defines which pieces of the system exist (a user interface, a server, a database), how they communicate (through APIs, message queues, direct calls), and what rules govern their design (each piece handles one job, pieces talk through agreed contracts, sensitive data stays in one place).

Architecture matters because it determines how easy or hard it is to change things later. A well-designed architecture lets you redesign the user interface without touching the database, or swap one payment provider for another without rewriting the whole application. A poorly designed architecture means every change ripples through the entire system, breaking things in unexpected places.

The key insight: architecture is about the decisions that are expensive to reverse. Choosing a programming language, deciding whether the app is one codebase or many, defining how the frontend talks to the backend — these structural choices shape everything built on top of them.

In plain terms

Software architecture is like a city plan. Before building houses, roads, and parks, the city planner decides where each district goes, how roads connect them, and what rules govern construction (no factories next to schools). The plan doesn’t build anything — it makes sure everything built afterward fits together sensibly.

At a glance

Core structure of software architecture (click to expand)
graph TD
    SA[Software Architecture] --> COMP[Components]
    SA --> REL[Relationships]
    SA --> PRIN[Principles]
    SA --> CON[Constraints]
    COMP --> FE[Frontend]
    COMP --> BE[Backend]
    COMP --> DB[Database]
    REL --> API[APIs / Contracts]
    PRIN --> SoC[Separation of Concerns]
    PRIN --> ABS[Abstraction Layers]
    style SA fill:#4a9ede,color:#fff
Key: Architecture is built from four pillars. Components are the distinct parts of the system. Relationships define how they talk to each other. Principles are the design rules that keep things clean. Constraints are non-negotiable requirements (like privacy or performance) that shape every decision.

How does it work?

Software architecture has four core elements. Together, they form the “blueprint” that guides all development.

1. Components

The distinct parts of the system, each with a defined job. In a typical web application, the main components are:

Frontend — what the user sees and interacts with (the website or app)
Backend — the server-side logic that processes requests and enforces rules
Database — where data is stored and retrieved
External services — third-party systems the app relies on (payment processors, email services, map providers)

Think of it like...

Rooms in a house. The kitchen is for cooking, the bedroom is for sleeping, the bathroom is for washing. Each room has a clear purpose. You don’t cook in the bathroom — and in software, you don’t put database logic in the user interface.

Concept to explore

See client-server-model for how components are typically split between the user’s device and the server.

2. Relationships

How components communicate with each other. Components rarely work in isolation — the frontend needs data from the backend, the backend needs to read and write to the database.

Relationships are defined through:

APIs — structured requests and responses between frontend and backend
Database queries — how the backend reads and writes stored data
Events and messages — one component notifying another that something happened

The form of these relationships matters enormously. Direct, tightly coupled connections (where one component reaches into another’s internals) make the system fragile. Loosely coupled connections (through well-defined contracts) make the system flexible.

Concept to explore

See contracts-and-interfaces for how components agree on the format and rules of their communication.

3. Principles

The design rules that guide how components are built and how they interact. The three most important principles in software architecture are:

Principle	What it means	Why it matters
separation-of-concerns	Each part handles one job	You can change one part without breaking another
abstraction-layers	Hide complexity behind simple interfaces	You don’t need to understand everything to use something
contracts-and-interfaces	Agree on input/output formats	Parts can be built and tested independently

These principles reinforce each other. Separation of concerns tells you what to divide. Abstraction layers tell you how to hide the details. Contracts tell you how the parts communicate after being divided.

Rule of thumb

If changing one part of your system forces you to change three other parts, you have an architecture problem — most likely a violation of one of these principles.

4. Constraints

Non-negotiable requirements that shape architectural decisions. These aren’t features — they’re conditions the system must satisfy regardless of what it does.

Common constraints include:

Privacy — user data must stay in a specific jurisdiction, or be encrypted at rest
Performance — pages must load in under 2 seconds
Scalability — the system must handle 10x more users without a rewrite
Accessibility — the interface must work with screen readers
Budget — hosting must cost under a certain amount per month

Think of it like...

Building codes for a house. The architect can be creative with the floor plan, but the building must meet fire safety codes, support a minimum snow load, and have proper drainage. These constraints don’t limit creativity — they channel it toward solutions that actually work in the real world.

Why do we use it?

Key reasons

1. Changeability. Software is never “done” — requirements evolve, features are added, technology changes. Good architecture makes changes safe and localised instead of risky and system-wide.

2. Communication. Architecture gives teams a shared vocabulary. Saying “the API layer” or “the database schema” means everyone is talking about the same thing, whether they’re human developers or AI coding assistants.

3. Complexity management. Real systems have thousands of moving parts. Architecture breaks overwhelming complexity into manageable pieces, each small enough to understand and reason about.

4. Risk reduction. Expensive mistakes happen when structural decisions are made accidentally. Intentional architecture means you’ve considered trade-offs before committing to a path.

When do we use it?

When starting a new project and deciding how to structure the codebase
When a system has grown and changes keep breaking unrelated features
When multiple people (or AI assistants) are working on different parts of the same system
When choosing between build vs. buy for a component (e.g., using a third-party auth service vs. building your own)
When performance, privacy, or scalability requirements demand careful structural decisions

Rule of thumb

If the project will live longer than a weekend hackathon, spend time on architecture. The cost of getting it wrong compounds with every line of code built on top of it.

How can I think about it?

The city plan

A city plan is software architecture.

Residential districts, commercial zones, industrial areas are the components — each has a distinct purpose

Roads and public transport are the relationships — they define how people and goods move between districts

Zoning laws are the principles — factories can’t be built next to schools, buildings must have fire exits

Geography and budget are the constraints — a river limits where you can build, the municipal budget limits how many bridges you get

You don’t need to know the city plan to walk to the shops. But the planner needs to get it right, or traffic jams and flooding will plague the city for decades.

The human body

The human body is a well-architected system.

Organs are components — the heart pumps blood, the lungs handle oxygen, the stomach digests food

Blood vessels and nerves are relationships — they carry signals and resources between organs

Each organ does one job — this is separation of concerns

Organs communicate through defined interfaces — the heart doesn’t need to understand how the lungs extract oxygen; it just sends blood and gets oxygenated blood back

When one organ fails, doctors can often treat it without affecting the others — precisely because the architecture is well separated.

Concepts to explore next

Concept	What it covers	Status
client-server-model	The split between user-facing and server-side software	stub
separation-of-concerns	The principle of giving each part one job	complete
abstraction-layers	Hiding complexity behind simple interfaces	stub
contracts-and-interfaces	Agreeing on input/output formats between parts	complete
monolith-architecture	Building one unified codebase vs. many small services	stub
domain-driven-design	Structuring software around business domains	stub

Some of these cards don't exist yet

They’ll be created as the knowledge system grows. A broken link is a placeholder for future learning, not an error.

Check your understanding

Test yourself (click to expand)

Explain what software architecture is and why it’s different from simply writing code. What does it add?

Name the four core elements of software architecture and give one example of each from any web application.

Distinguish between a component and a relationship in architecture. Why do both matter?

Interpret this scenario: a team changes the design of their login page and the payment system breaks. What architectural principle was likely violated?

Connect software architecture to systems-thinking. How is designing software similar to understanding any complex system?

Where this concept fits

Position in the knowledge graph
graph TD
    SD[Software Development] --> SA[Software Architecture]
    SD --> IT[Iterative Development]
    SA --> CSM[Client-Server Model]
    SA --> SoC[Separation of Concerns]
    SA --> ABS[Abstraction Layers]
    SA --> CI[Contracts and Interfaces]
    SA --> MON[Monolith Architecture]
    SA --> DDD[Domain-Driven Design]
    style SA fill:#4a9ede,color:#fff
Related concepts:

systems-thinking — provides the theoretical foundation for reasoning about interconnected parts and emergent behaviour

iterative-development — architecture evolves through repeated cycles of design, build, and feedback

Yiuno

Explorer

Software Architecture

Software Architecture

What is it?

At a glance

How does it work?

1. Components

2. Relationships

3. Principles

4. Constraints

Why do we use it?

When do we use it?

How can I think about it?

Concepts to explore next

Check your understanding

Where this concept fits

Further reading

Graph View

Table of Contents

Backlinks