Start here: from writing code to shaping systems

Software architecture is the set of decisions that are hard to change later: which qualities the system must have, how it's split into parts, how those parts talk and share data, and which rules keep it that way. You don't need the title "architect" to learn it. You need to see the trade-off in every choice, and practise explaining why you chose one side.

1. What software architecture is

An architecture has four parts, and you'll meet each one in this track:

2. The architect's process, step by step

Press Play to watch one architecture take shape for an online auction site. Notice that every arrow turns one thing into another: requirements into characteristics, a workflow into components, both into a style, and the choice into a written decision.

Every step was a choice with a cost. That's the first law of software architecture: everything is a trade-off. If you think you've found something with no trade-off, you just haven't found the trade-off yet. The second law: why is more important than how. A diagram shows how the system is built; only the recorded reasons let the next person decide whether to change it.

3. Architecture or design?

There's no hard line between the two: it's a spectrum. Three questions place any decision on it. The more "yes" answers, the more it's an architecture decision, and the more care and agreement it needs.

Try it: for each decision, place it on the spectrum yourself, then see where the three questions put it.

4. How this track teaches

Every module has the same ten sections: the idea with an everyday analogy, an animation of how it works, a lab, trade-offs, how it plays out in real projects (with what to say in an interview), a memory hook, common mistakes, a design exercise, a quiz, and where to go deeper.

The animations show the mechanism, not just boxes: what moves, in what order, what changes state, and what breaks. Step through them slowly the first time, and replay the step that surprised you.

5. What you need

• Some experience building software. You should have worked on a codebase with other people. You don't need to have designed one.
• The System design basics help. If servers, databases and queues are new to you, read System design Level 0 first: about two hours.
• A notebook. Architecture is learned by deciding and writing down why. Section 7 shows how.

6. The daily routine (45 minutes)

7. Your architecture notebook

Keep one page per decision you make or study, in the shape of an architecture decision record:

Title:        Use asynchronous messaging for bid capture
Context:      Up to 2,000 bids/second at auction close; bidders need an instant "received".
Decision:     Bid capture publishes to a queue; the bid tracker consumes in order per auction.
Trade-offs:   + elasticity, responsiveness   − harder testing, eventual consistency
Revisit when: one queue partition can't keep up with a single hot auction

After a few weeks you'll have a personal catalogue of decisions with their reasons, which is exactly what architecture interviews probe.

8. Self-check quiz

9. Glossary

Every dotted word on the software architecture pages, in one place. New terms are added as each module is published.

10. Where to go next