Architecture Style
A system-level organising shape — layered, modular monolith, service-based, microservices, event-driven, space-based — chosen for the properties it makes cheap.
A style is a system-level shape; a pattern solves a problem inside one. Choosing a style is choosing which properties are cheap and which are expensive for the rest of the system's life.
| Style | Makes cheap | Makes expensive |
|---|---|---|
| Layered monolith | Simplicity, transactions, local reasoning | Independent scaling and deployment |
| Modular monolith | The above plus enforced boundaries | Team autonomy, per-module scaling |
| Service-based (a few coarse services) | Partial independence, moderate ops cost | Fine-grained scaling |
| Microservices | Independent deploy, scale, tech choice | Consistency, debugging, ops headcount |
| Event-driven | Decoupling, buffering, extensibility | Ordering, exactly-once reasoning, tracing |
| Space-based | Extreme elastic throughput | Data consistency and operational skill |
Industry example
Netflix's decomposition from a monolithic DVD-era application to hundreds of independently deployable services is the standard reference, and it is usually cited for the wrong reason. The driver was not that microservices are better; it was a specific, painful event — a database corruption that halted shipping for days — which reframed the requirement as no single failure should be able to stop the whole business.
What is less often copied is everything Netflix had to build to make the style survivable: client-side load balancing and service discovery, standardised resilience libraries so every caller had timeouts and bulkheads by default, deep request tracing, and a culture of deliberately injecting failure so degradation paths were exercised before customers found them. The style was affordable because that platform investment was made. Adopting the style without the platform is where most imitations fail.
How to choose
Start from the drivers. If independent deployment by many teams is a driver, you are heading toward services. If transactional correctness over a rich domain is a driver, you are heading toward a monolith. If unpredictable burst throughput dominates and the data is partitionable, a space-based or partitioned design becomes attractive. Most systems have one dominant driver and should pick the style that serves it, accepting the rest as costs.
Trade-off
Styles can be mixed and usually should be: a modular monolith with two extracted services and one event stream is an extremely common and entirely respectable answer. Purity is not a quality attribute.
Interview question
"Name the architectural style you would choose for a new B2B SaaS product with six engineers, and tell me what would have to change for you to choose differently."