Forty-six modules take you from "what does an architect actually do?" to architecture characteristics, modularity, code-level design and Domain-Driven Design, teams, the major architecture styles and the frontend, integration, the cloud and AI components, operational and analytical data, security, keeping an architecture healthy as it grows, and the strategy and influence that make up the rest of the architect's job. Every idea is explained plainly, animated step by step so you can see the mechanism, and tried in a lab where you make the decision yourself.
System design asks "which building blocks does this one system need to handle its load?" Software architecture asks a wider set of questions: which qualities matter most to the business, how the code is split into parts, which architecture style fits, how the parts talk and share data, and how the structure is kept healthy for years. Architects are judged less on knowing the "right" answer and more on finding the trade-offs, choosing deliberately, and explaining why.
| Track | The central question | Typical interview prompt |
|---|---|---|
| System design | Which components, and how many, make this system fast and reliable at scale? | "Design a URL shortener for 100 million users." |
| Software architecture | Which qualities matter, which structure and style deliver them, and what do we give up? | "Our monolith takes three weeks to release. What would you change, and how would you justify it?" |
The two overlap, and the modules link across: sagas, CAP and caching appear in both tracks, seen from different angles.
Every module has the same ten sections, so you always know where to look:
An everyday analogy and a plain explanation, an animation that shows the mechanism step by step, then a lab where you make the call yourself.
The trade-offs: what each option gives and costs. Then how it plays out in real projects, and what to say in an interview.
A memory hook with a full explanation, common mistakes, a design exercise to do on paper, a quiz, and the best resources to go deeper.
Real decisions mix ideas from many modules. Each case study follows one application through a decision, from the drivers and options to the ADR, the numbers and what happened. Some are real companies analysed from their own engineering write-ups; others are invented companies, used where the story needs internal detail nobody publishes. All case studies →
About 45 minutes a day, five days a week, using the routine on the Start here page: read on Monday, redo the lab and exercise on Tuesday, sketch from memory on Wednesday, apply the idea to a system you know on Thursday, and explain it out loud on Friday.
| Week | Study | Output by Friday |
|---|
What architecture is, the architect's process animated end to end, two laws, the daily routine and the glossary.
ADR, weighted scorecard, review checklist, RFC, disaster recovery plan and cost projection, ready to copy.
The building blocks: load balancers, caches, databases, queues, and 46 worked designs.
The coding track: 24 patterns that solve most coding interview problems.