A monolith, microservices, an event-driven system and a dozen other styles, each used to build the same city bike-share service, Pedal: unlock a bike, ride, return it, pay. Every page draws the parts, walks one rental through them, runs real code in Python, TypeScript and Java, and gives you something to try. Because the app never changes, you can see exactly what each style buys and what it costs.
The Software architecture track teaches how an architect thinks: characteristics, trade-offs, decisions, governance. This track is the catalogue that goes with it: one hands-on page per style, built around code you can run and change. Each page links to the matching Architecture module for the reasoning.
How each style builds Pedal. Read across a row for one style; read down a column to see the choices that differ.
| Style | Deploys as | Parts talk by | Data lives | Pick it when |
|---|---|---|---|---|
| Monolith | One app | Function calls | One database | One team, a new product, or a domain still being discovered |
| Layered | One app | Calls down the stack | One database, behind the bottom layer | Mostly forms over data; a team that knows the pattern |
| Hexagonal | One app | Ports (interfaces) and adapters | Behind a port | Real business rules that must outlive frameworks and vendors |
| Clean and onion | One app | Inward-pointing dependencies | Outermost ring | Large codebases where the rules need protecting from churn |
| Microkernel | Core + plugins | Plugin contracts | Core, plus plugin-owned | Many variants on a stable core: per city, per customer, per product |
| Client-server and tiers | Clients + server tiers | Requests and responses | The data tier | Almost always, as the outer shape of the other styles |
| Service-based and SOA | A handful of services | Calls, sometimes a shared bus | Often one shared database | Clear domains, a few teams, no appetite for dozens of services |
| Microservices | Many small services | Calls and events | One store per service | Many teams that must ship independently, uneven scaling |
| Serverless | Functions on a platform | Events and HTTP | Managed stores | Spiky or low traffic, small team, glue between managed services |
| Event-driven | Producers + consumers | Events through a broker or log | Each consumer's own | Many reactions to one fact, or work that can happen later |
| Pipes and filters | A chain of steps | Data passed along | Flowing through | Batch or stream processing, ETL, report building |
| Broker | Clients, a broker, servers | Requests via the broker | Each server's own | Callers shouldn't know where or how many servers there are |
| Space-based | Processing units + data grid | Replicated memory | In memory, written behind | Extreme, spiky load on hot data (a city-wide ride surge) |
| Peer-to-peer | Equal peers | Peers directly | Spread across peers | No central party can or should be trusted or paid for |
| Cell-based | Many copies of the whole system | A thin router in front | Per cell | A failure must never reach more than a slice of customers |
About 40 minutes a day. Before reading a page, sketch Pedal in that style yourself for ten minutes, then compare.
| Week | Study | Output by Friday |
|---|