Architect's "Treasure Map": Understanding Software Architecture Styles and Patterns in One Diagram

Software Architecture Styles and Patterns

In the world of software engineering, architecture is our blueprint. It determines the skeleton of the system, the division of components, and how they interact. This diagram shows that software architecture is not a single choice but a broad spectrum of possibilities.

1. Composition (By Composition): Viewing the System as a Collection of Services

• Microservices: The opposite of a monolith. The application is split into a set of small, independently deployable services. Each service is built around a business capability and communicates via lightweight APIs (e.g., REST). This greatly enhances scalability, flexibility, and team autonomy.
• Nanoservices: An even more extreme form of microservices, with service granularity “smaller than microservices.” In practice, this is often considered an anti‑pattern because it can lead to excessive complexity and network overhead.
• Layers (Layered Architecture): The classic N‑tier architecture. The system is horizontally divided into presentation, business logic, data access layers, etc. This is a clear separation of concerns and forms the basis for many monoliths and service‑oriented architectures.
• Microkernel & Plug‑ins (Microkernel and Plugins): Also known as plugin architecture. The system has a minimal core (Microkernel), and other advanced features are added via “plugins.” This architecture is highly extensible; well‑known examples include VS Code, Eclipse, and even browsers.
• Components: View the system as a collection of replaceable, reusable components. It emphasizes modularity and interface definition.
• Layers (Layered Architecture): Classic N‑tier architecture. The system is horizontally divided into presentation, business logic, data access layers, etc. This is a clear separation of concerns and forms the basis for many monoliths and service‑oriented architectures.

2. Connections (By Connections): How Do Components "Talk" to Each Other?

• REST (Representational State Transfer): The de facto standard for Web APIs today. It uses standard HTTP methods (GET, POST, PUT, DELETE) to operate on resources, is stateless, and easy to understand.
• Client‑Server RPC: A tighter communication method. The client calls server functions as if invoking local functions (e.g., gRPC). It offers high performance but has stronger coupling than REST.
• SOA (Service‑Oriented Architecture): The predecessor of microservices. SOA also promotes service orientation but typically relies on heavier protocols (e.g., SOAP) and a centralized “Enterprise Service Bus” (ESB) for inter‑service coordination.
• Peer‑to‑Peer (P2P): A decentralized architecture. Each node in the network is both client and server, communicating directly without a central coordinator. Blockchain and BitTorrent are typical P2P applications.
• Backend for Frontend (BFF): An API pattern. It does not create a single generic backend for all clients but instead creates a dedicated backend service for each client type (e.g., web, iOS, Android). The BFF aggregates and trims data to perfectly fit the specific front‑end needs.

3. Events (By Events): How Does the System "Respond" to Changes?

• Pub/Sub (Publish/Subscribe): The most basic event pattern. Services (publishers) send events to a “topic” without knowing who is listening. Other services (subscribers) can subscribe to topics of interest to receive events.
• Reactive: More of a set of principles. Systems should be responsive, resilient, elastic, and message‑driven, ensuring timely responses under high concurrency and failures.
• Event Sourcing: A fundamental shift. It does not store the object’s final state but stores all events that led to that state (change history). The system’s current state is derived by replaying these events.
• CQRS (Command Query Responsibility Segregation): A pattern that separates “write” operations (commands) from “read” operations (queries). The write model focuses on business logic and validation, while the read model is highly optimized for queries. CQRS is often used with Event Sourcing.

4. Streams (By Stream): How to Handle "Flowing" Data?

• Pipe & Filters: A classic data‑processing pattern. Data flows through a series of independent “filters,” each performing a single transformation and passing the result to the next via a “pipe.”
• Brokers: Use a centralized message broker (e.g., Kafka, RabbitMQ) to manage data streams. Producers send streams to the broker, and consumers pull streams from it. This is the core component for implementing Pub/Sub and stream processing.
• Fast Data: Refers to real‑time data that needs immediate processing. This is an architectural style for low‑latency, high‑throughput scenarios (e.g., financial trading, IoT).

5. Data (By Data): How to Organize and Manage "Data"?

• Data Warehouse: A large, centralized repository primarily used to store historical structured data from various business systems, optimized for business intelligence (BI) and analytics reporting.
• Data‑Centric: A philosophy that treats data as the enterprise’s most core and enduring asset, with applications built as pluggable components around that data.
• Data Mesh: A modern, decentralized data architecture. It opposes centralized data warehouses and advocates partitioning data by business domain, with each domain team owning and providing it as a “data product.”
• Data Fabric: An intelligent “virtualized” data layer. It does not move data but provides a unified data access and governance view over multiple heterogeneous data sources through metadata management and AI technologies.

6. Purpose (By Purpose): What Is the System Used For?

• API Platform / Developer Platform: The primary “users” of these systems are developers. They provide a set of tools, services, and APIs aimed at accelerating application development and delivery for other teams.
• Integration Hub: A platform focused on connecting different (often heterogeneous) systems and applications. It handles data transformation, protocol adaptation, and process orchestration.
• Dev Portal: Usually part of an API platform, it serves as the storefront for developers to discover, learn, test, and manage APIs.

Summary: Architecture Is a Game of "Choices"

This mind map clearly shows that software architecture is not a single option but a broad spectrum. More importantly, these categories are not mutually exclusive. A modern system is almost always a hybrid of these patterns:

You might have a Microservices‑based Developer Platform, with services communicating via REST and Pub/Sub, and adopting a Data Mesh approach to data management.

As developers and architects, our job is to understand this “treasure map” and, based on business requirements, team size, performance goals, and maintainability—principles—select and combine the most suitable solutions from the toolbox.