Software Architecture Patterns (Richards, 2015)
A compact catalog of layered, event-driven, microkernel, microservices, and space-based styles. Its topology sketches remain useful, while its universal scorecard and several distributed-system recommendations need current qualification.
Mark Richards's 2015 O'Reilly report is a compact catalog of five system-level architecture styles. Its durable contribution is the combination of a topology, a characteristic interaction model, and an explicit cost discussion for each style. It is not a current standard and its final up/down scorecard is not a decision procedure.
What the source covers #
| Style | Organizing constraint | Useful source contribution |
|---|---|---|
| Layered | dependencies follow horizontal responsibility layers | closed versus open layers, pass-through layers, and the sinkhole failure mode |
| Event-driven | producers and consumers communicate through asynchronous events | broker choreography versus mediator coordination and the loss of one obvious transaction boundary |
| Microkernel | a stable core exposes contracts to independently varying plugins | plugin registry, extension contracts, and product-specific behavior outside the core |
| Microservices | business capabilities become separately deployable network services | service granularity, deployment independence, and several communication topologies |
| Space-based | processing and hot state are partitioned or replicated across an in-memory grid | processing units plus messaging, data, processing, and deployment coordination grids |
The figures are readable topology sketches, but GTK does not retain or redraw them one-for-one. The topic entry instead synthesizes the decision dimensions the five sketches expose: deployment unit, communication, state ownership, consistency boundary, scaling unit, and failure isolation.
Current qualifications #
The book predates today's mainstream container orchestration, service meshes, managed event platforms, and cloud well-architected guidance. The mechanisms still matter, but several recommendations cannot be carried forward literally:
- A microservice is not defined by being small or by using REST. The load-bearing property is independent change and deployment around a coherent business capability; shared databases and lockstep releases usually negate that property.
- Choreography and orchestration are both valid. Choreography removes a central workflow owner but can hide the end-to-end process; orchestration makes coordination explicit but creates a component whose availability and coupling must be designed.
- Asynchronous events do not remove coupling. They move it into schemas, semantic meaning, ordering, delivery, replay, idempotency, and observability.
- A distributed in-memory grid does not provide "near-infinite" scalability. Partition skew, replication, cross-partition operations, persistence, rebalancing, coordination, and memory cost remain finite bottlenecks.
- Style ratings such as "high scalability" or "low testability" are conditional on a workload and implementation. A specific quality-attribute scenario is needed before a rating is meaningful.
Source defects not propagated #
The inspected second release contains several editing errors. The microkernel chapter twice says "microservices" where its surrounding mechanism clearly means microkernel. The microservices deployment analysis repeats mediator-versus-broker prose from the event-driven chapter. One space-based footer labels the chapter as Chapter 0. These errors are recorded in the audit and excluded from GTK content.
Evidentiary role #
Use this report for the five-style catalog, topology vocabulary, and historically representative 2015 tradeoff discussion. Use current primary or official sources for architecture-description semantics, quality-attribute evaluation, service data autonomy, coordination choices, event delivery, and distributed data-grid behavior.