In this chapter
We'll learn what software architecture is — the blueprint of a system, not its code — and the most common starting shape: the monolith, everything under one roof, and its tidier cousin, the modular monolith.
The Problem in Real Life
Week fourteen, Friday, 7:00 PM. Tickets go on sale for a small comedy show — about 2,000 fans. At 7:00:20, BlueTicket's site starts answering 503 Service Unavailable. At 7:01, it stops answering at all. It takes twelve minutes to come back.
On Monday, the countdown board Samantha hung on the wall reads SALE DAY — 182 days. Anna stares at it. "Two thousand people took us down," she says quietly. "On Sale Day there'll be fifty thousand."
John hands her a marker. "Then before we fix anything, we draw what we actually have. Not the code — the shape. That shape has a name: architecture."
If 2,000 broke it, what will 50,000 do?
Anna
Writing Code vs. Designing the Shape of a System
Small worked, big didn't
The system was fine for a few hundred fans. Its shape couldn't handle thousands.
Code isn't the whole story
Good code inside a bad structure still falls over. The structure is a separate decision.
Everything in one box
All of BlueTicket — pages, pricing, holds, emails, SMS — runs as one program on one server.
What Is Software Architecture?
The building blueprint analogy: before a building goes up, an architect decides its big shape: how many floors, where the stairs and lifts go, where water and electricity run, which walls hold up the roof. Those decisions are hard to change once people move in. The bricklayers then build each wall well — but no amount of good bricklaying fixes a building with one tiny staircase for a thousand people.
Software architecture is the same idea for software: the big decisions about how a system is split into parts, how those parts talk to each other, where data lives, and how it all runs. Code is the bricks; architecture is the blueprint. Application architecture is the architecture of one application — like BlueTicket itself.
Most systems start with the simplest possible shape.
- Monolith — a department store under one roof: a monolith is an application built and run as one single program: the web pages, the pricing rules, the seat holds, the payments, the emails and the SMS are all inside one codebase, deployed together, running as one process (Act 04). Like a big department store: clothing, food, electronics and a café, all in one building with one front door.
- Why monoliths are great at the start: everything is in one place, so it's simple to build, test, run and deploy. One codebase to read, one thing to start. Most successful companies — including BlueTicket — began as a monolith, and that was the right choice.
- Where monoliths hurt: if the store catches fire, every department closes, not just one. If the café gets a sudden rush, the whole building gets crowded. And renovating one department means closing parts of the whole store. In software: one bug can crash everything, one busy feature slows everything, and every change means redeploying the whole program.
- Modular monolith — the same store, with proper departments: a modular monolith is still one program, deployed as one unit, but organised inside into clear modules with walls and doors: a pricing module, a holds module, a payments module, a notifications module. Each module owns its part and talks to others only through clear functions — like the modularity from Act 07, at the scale of a whole application. You keep the simplicity of one program, while avoiding a tangled mess inside.
| Feature | Monolith | Modular monolith |
|---|---|---|
| Deployed as | One program | One program |
| Inside | Can become tangled | Clear modules with boundaries |
| Building version | A store with everything mixed together | A store with walled departments |
| Good for | Getting started fast | Growing without a tangled mess |
| Main risk | Hard to change safely as it grows | Still one unit to deploy and scale |
| Feature | Architecture | Code |
|---|---|---|
| Building version | The blueprint | The bricks and walls |
| Decides | Parts, connections, where data lives, how it runs | How each part does its job |
| Changing it later | Hard and expensive | Usually easier |
| Example | "Payments run as a separate service" | "calculateTotal applies the student discount" |
BlueTicket today: a monolith on one server
Fans' browsers and apps
thousands of clients
CDN
images, styles, scripts (Act 12)
ONE server running the monolith
pages · API · pricing · holds · payments · emails · SMS
ONE PostgreSQL
bookings, seats, fans
ONE Redis
sessions, caches
What Anna draws: a box for fans' browsers, an arrow to the CDN, an arrow to one server, and inside that one server, everything: the website, the API, pricing, holds, payments, emails and SMS. From that one box, arrows go to one PostgreSQL database and one Redis. BlueTicket is a monolith — fairly well organised inside, almost a modular monolith — running on a single machine.
"Is the monolith the problem?" she asks. John shakes his head. "Not by itself. Plenty of huge companies run monoliths. The problem is that ours is one copy, on one machine, doing slow jobs while fans wait. We'll fix those one by one — and we may never need to break the monolith apart at all." This Act walks through exactly those fixes.
Key Takeaway
Software architecture is the blueprint of a system: how it's split into parts, how they talk, where data lives and how it runs — decisions that are hard to change later. A monolith is one program containing everything, like a department store under one roof: simple to build and run, but one failure or one rush affects everything. A modular monolith keeps one program but organises it into clear modules.
Why This Matters
Architecture decides what a system can survive. BlueTicket's code was good enough — but its shape couldn't handle 2,000 fans at once, never mind 50,000. Understanding architecture is how engineers move from "my feature works" to "the whole system works under real load." The System Design Fundamentals course goes much deeper into these decisions.
Anna has drawn one big box. To improve it, she first needs to see the layers inside every web application — the standard way systems are cut into parts.