Architecture Styles

What an architecture style is, how it differs from a pattern, and how to read each style's characteristics scorecard before you commit to one.

The orthogonal axis that decides whether your code is organized by technical layer or by business domain — and why it must match your teams and your changes.

The eight false assumptions that make distributed styles powerful but costly — what breaks, why, and what it means for choosing monolithic vs distributed.

The n-tier default monolith — horizontal layers, closed-vs-open isolation, the sinkhole anti-pattern, and why it is cheap and simple but hard to scale.

The pipes-and-filters monolith — stateless single-task filters connected by one-way pipes, behind Unix shells, ETL, and stream processing.

The plug-in style — a minimal core plus independent plug-ins, ideal for product-based and customizable apps, and the only style that can be technical OR domain partitioned.

The pragmatic distributed style — a separate UI, a handful of coarse-grained domain services, and a shared database, giving modularity and ACID without microservices' cost.

The asynchronous, decoupled style of event processors reacting to events — broker vs mediator topology, the highest balanced scalability and fault tolerance, and the error-handling hard parts.

The extreme-scalability style that removes the database from the transaction path — replicated in-memory data grids, processing units, virtualized middleware, and async data pumps.

The domain-partitioned distributed style built on bounded contexts — single-purpose services, distributed data, operational automation, and the agility champion that pays in performance and cost.

The consolidated scorecard — every style rated across partitioning, cost, simplicity, scalability, fault tolerance, performance, and more — and how to read it for trade-offs.

The decision process — monolith vs distributed via the quantum, where data lives, sync vs async — plus worked monolith and distributed case studies.