Choosing the Right Architecture Pattern: Layered, Event‑Driven, Microkernel, Microservices & More

This article is a set of notes taken while reading O'Reilly's free e‑book Software Architecture Patterns . The book, published in March 2015, analyzes and compares several popular architecture styles beyond the traditional N‑tier model.

The author, Mark Richards, has over 30 years of industry experience, mainly on Java platforms, and has written several books and papers.

For readers who lack time to read the whole book, these notes capture the main knowledge points.

Layered Architecture

Also known as N‑tier architecture, it is the most common pattern, especially in Java EE applications. It divides the system into layers such as presentation, business, persistence, and database.

Pattern Description

Each layer represents a functional concern. The number of layers is not fixed; small applications may combine business and persistence, while large systems may add additional layers (e.g., a service layer).

Key Concepts

Each layer is closed: a request must pass through every layer to reach the bottom.

Layer isolation means changes in one layer do not affect others, and a layer does not need to know the implementation details of other layers (e.g., the business layer does not need to know whether persistence uses Hibernate or MyBatis).

Layers can be added or opened (allowing a higher layer to bypass a lower one) when necessary.

Architecture Example

Taobao's early architecture is a classic layered design, with optional sub‑layers such as a service layer.

Architecture Considerations

Layered architecture is a reliable, generic choice for many applications, especially when the appropriate pattern is unclear.

Watch out for the "architecture sinkhole" anti‑pattern, where layers pass requests with little or no business logic. If more than 20% of requests follow this pattern, consider opening some layers.

Potential drawbacks include increased size, distribution complexity, reduced robustness, and performance or scalability concerns.

Pattern Analysis

Overall flexibility: Low

Ease of deployment: Low

Testability: High

Performance: Low

Scalability: Low

Development ease: High

Event‑Driven Architecture

A popular distributed asynchronous pattern suitable for large‑scale applications. It consists of highly decoupled, single‑purpose event‑handling components that receive and process events asynchronously.

Mediator Topology

Suitable for multi‑step events that require ordered processing, such as a stock trade that must be validated, brokered, commission‑calculated, and finally confirmed.

Components: event queues, an event mediator, event channels, and event processors.

Clients send events to queues; the mediator forwards them to channels, where processors handle the business logic. Event channels can be queues or topics, allowing multiple processors to consume the same event.

Open‑source implementations include Spring Integration, Apache Camel, and Mule ESB.

Broker Topology

There is no central mediator; events are linked through a lightweight broker such as RabbitMQ, ActiveMQ, or HornetQ. This is suitable when events are simple and do not need re‑orchestration.

Architecture Example

Early Sina Weibo used a synchronous push model, causing massive database writes during high‑traffic events. It later switched to an asynchronous push‑pull model, writing posts to a message queue and returning immediately to the user.

Architecture Considerations

Implementation complexity arises from asynchrony and distribution, leading to issues such as broker reconnection, availability, and lack of atomic transactions across processors.

Pattern Analysis

Overall flexibility: High

Ease of deployment: High

Testability: Low

Performance: High

Scalability: High

Development ease: Low

Microkernel Architecture

Also known as plugin architecture, it separates a core system from extensible plug‑in modules. Eclipse IDE is a classic example.

Pattern Description

The core provides fundamental services, while plug‑ins add optional features, enabling extensibility, flexibility, and feature isolation.

Architecture Considerations

The microkernel can be embedded within other architectures, supporting incremental evolution and product‑based applications.

Pattern Analysis

Overall flexibility: High

Ease of deployment: High

Testability: High

Performance: High

Scalability: Low

Development ease: Low

Microservices Architecture

Microservices are an evolution of monolithic and SOA approaches, offering independently deployable units that can be scaled and evolved separately.

Pattern Description

Key concepts include separately deployed units, service components, and distributed communication (JMS, AMQP, REST, SOAP, RMI, etc.). Properly sizing service components is a major challenge.

Pattern Topologies

API REST‑based: Small, self‑contained services exposed via HTTP APIs (e.g., OAuth2).

Application REST‑based: Clients interact with a UI layer that calls backend services.

Centralized messaging: A lightweight broker (e.g., RabbitMQ) replaces REST calls, handling routing without full orchestration.

Architecture Considerations

Microservices address the problems of monolithic codebases and traditional SOA, enabling rapid product releases but also inheriting distributed system challenges.

Pattern Analysis

Overall flexibility: High

Ease of deployment: High

Testability: High

Performance: Low

Scalability: High

Development ease: High

Space‑Based Architecture

Also called cloud‑based architecture, it tackles scalability and concurrency by eliminating a central database bottleneck and using a replicated in‑memory grid.

Pattern Description

Applications store data in the memory of all active processing units, which can be added or removed dynamically. The two main components are processing units and virtualized middleware that manage data synchronization and communication.

Architecture Considerations

Space‑based architecture is complex and costly; it suits variable‑load web applications but is less appropriate for large relational‑database workloads.

Pattern Analysis

Overall flexibility: High

Ease of deployment: High

Testability: Low

Performance: High

Scalability: High

Development ease: Low

Source: http://www.uml.org.cn/zjjs/201705272.asp