1.2 Software Architecture
Software architecture turns business intent into running systems. The four mainstream styles - layered (monolith), client-server, microservices, and event-driven - each trade off ease of build against scale, blast radius, and ownership. This lesson contrasts them with a single decision lens.
Style Comparison
The choice of architecture style determines how a system scales, how easily teams can ship changes independently, and how failures propagate.
Figure 5.1 - Four common software-architecture styles arranged from most-coupled to most-decoupled.
When Each Style Fits
| Style | Best For | Avoid When | Typical Team |
|---|---|---|---|
| Layered (monolith) | One product, one DB, small team, fast time-to-market | You need independent deploys per feature | 1-15 devs |
| Client-Server | Desktop apps with shared DB, internal LAN tools | Mobile-first, web-scale traffic | 5-30 devs |
| Microservices | Multiple bounded contexts, strict uptime SLAs | Single team without DevOps maturity | 30+ devs across 5+ pods |
| Event-Driven | Async workflows, integration hubs, IoT ingest | Hard request-response UX where latency is sensitive | Mixed product + platform |
Decision Lens
The biggest mistake is jumping to microservices early. Start with a well-modularised monolith. Split out a service only when you have **a real reason** - independent scale, independent ownership, or independent release cadence.
Discussion
Loading…