Start here: one app, many architectures
An architecture style is a set of big structural choices that tend to go together: how many things you deploy, how the parts talk, where the data lives, and which way dependencies point. This page introduces Pedal, the app every style page builds, and shows how to read the pages.
1. What a style is
Every style answers four questions, and the pages in this track always come back to them:
| Question | Two very different answers |
|---|---|
| How many things do we deploy? | One application (monolith) · dozens of services (microservices) |
| How do the parts talk? | Direct calls that wait for an answer · events that nobody waits for |
| Where does the data live? | One shared database · one store per part |
| Which way do dependencies point? | Business rules depend on the database · the database plugs into the rules |
Styles are not exclusive. A real system is usually a few styles at different sizes: microservices on the outside, each one hexagonal inside, talking through events. Page 16 is about combining them. The ideas behind the choice (characteristics, trade-offs, decision records) are taught in the Software architecture track; this one shows each style built and running.
2. Meet Pedal
Pedal runs a city bike-share: 400 docking stations, 6,000 bikes, about 60,000 rides on a weekday, with a sharp peak between 8 and 9 in the morning. Every style page builds the same core flow:
- Unlock. A rider scans a dock's code in the app; Pedal checks the account and payment method, and the dock releases a bike.
- Ride. The ride is open; the bike is "in use".
- Return. The rider docks the bike at any station with a free slot; the ride closes.
- Pay. Price the ride and charge the card. Pay-as-you-go: £1.00 to unlock plus £0.10 a minute. Members: no unlock fee and 30 free minutes, then £0.10 a minute.
Around that core sit the parts that make each style's trade-offs visible: rebalancing crews who move bikes from full docks to empty ones, dock hardware that sends status every few seconds, monthly reports for the city, and new cities that each want slightly different rules.
3. How to read a style page
| Section | What it gives you |
|---|---|
| 1 · In one picture | An everyday analogy and the parts the style defines |
| 2 · Pedal built this way | A numbered figure following one rental through the parts |
| 3 · The rules | The few rules that make it this style, and what breaking each looks like |
| 4 · How it goes wrong | The common ways teams end up with the costs and not the benefits |
| 5 · The code | A small program in Python, TypeScript and Java, compiled and run before publishing |
| 6 · Try it | A lab or simulator for the style's central trade-off |
| 7 · What it costs | Gains, pains, and which style to pick instead in which situation |
| 8 · Signs you've outgrown it | The symptoms that say it's time to move on |
| 9 · Remember it and say it | A memory hook, and how to talk about it in an interview or design review |
| 10–11 | A short quiz (it feeds the review deck) and further reading |
4. Words every page uses
- Deployable unit: something you build and release on its own. A monolith has one; microservices have many.
- Coupling: how much one part must change when another does. Explained in depth in Architecture module 07.
- Characteristics (or quality attributes): how well the system must do its job: speed, availability, scalability, ease of change. See module 04.
- Trade-off: improving one characteristic at the cost of another. Every style is a bundle of trade-offs; module 06 shows how to weigh them.
5. Check yourself
Which of these is an architecture style decision rather than a detail?
Can one system use several styles?
6. Glossary
Every dotted word in this track, in one place.