Common Software Architecture Patterns and Their Comparisons

Before starting the main code development of a large enterprise system, it is crucial to choose a suitable architectural style that provides the required functionality and quality attributes. This article introduces ten common software architecture patterns, describes their purposes, strengths, weaknesses, and typical applications.

What is an Architecture Pattern? According to Wikipedia, an architecture pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context, similar to a design pattern but with a broader scope.

Layered Pattern This pattern structures a program into layers, each offering services to the layer above. The typical four‑layer division for information systems is:

Presentation layer – the UI layer.

Application layer – the service layer.

Business logic layer – the domain layer.

Data access layer – the persistence layer.

Applications: general desktop applications, e‑commerce web applications.

Client‑Server Pattern Consists of a server and multiple clients; the server provides services to the clients, which send requests and receive responses.

Applications: online services such as email, file sharing, banking.

Master‑Slave Pattern Divides the system into a master module that distributes work to slave modules and aggregates their results.

Applications: database replication (master DB with synchronized slaves), peripheral devices on a system bus.

Pipe‑Filter Pattern Builds systems that produce and process data streams; each processing step is a filter component, and data flows through a pipeline.

Applications: compilers (lexical analysis → parsing → syntax analysis → code generation), bio‑informatics workflows.

Broker Pattern Uses decoupled components that interact via remote service calls; a broker component coordinates communication between clients and service providers.

Applications: message‑broker software such as Apache ActiveMQ, Apache Kafka, RabbitMQ, JBoss Messaging.

P2P Pattern Each component (peer) can act as both client and server, allowing dynamic role changes.

Applications: file‑sharing networks (Gnutella, G2), P2P TV protocols, cryptocurrency platforms like Bitcoin.

Event‑Bus Pattern Involves four key components: event source, event listener, channel, and event bus. Sources publish messages to channels; listeners subscribe to channels and receive notifications.

Applications: Android development, notification services.

MVC Pattern Separates an interactive application into Model (core data and logic), View (user interface), and Controller (input handling).

Applications: mainstream web application frameworks such as Django and Rails.

Blackboard Pattern Useful for problems without a deterministic solution; consists of a shared blackboard (global memory), knowledge sources (specialised modules), and a control component that selects and executes modules.

Applications: speech recognition, vehicle tracking, protein structure identification, sonar signal interpretation.

Interpreter Pattern Designs components that interpret programs written in a specific language, defining a class for each language symbol.

Applications: database query languages like SQL, protocol description languages.

Pattern

Advantages

Disadvantages

Layered

Lower layers can be reused by multiple higher layers; clear separation makes standardisation easy; changes in one layer do not affect others.

Not universally applicable; some scenarios require skipping layers.

Client‑Server (CS)

Easy to model a series of services for client requests.

Requests are handled in different server threads; inter‑process communication can cause high load.

Master‑Slave

Accuracy – execution delegated to distinct slave modules.

Slaves are independent with no shared state; communication latency between master and slaves may be problematic.

Pipe‑Filter

Supports concurrent processing; easy to add or replace filters; reusable filters enable flexible pipelines.

Overall efficiency limited by the slowest filter; data conversion overhead between filters.

Broker

Allows dynamic modification, addition, deletion, and relocation of objects; transparent content distribution for developers.

Requires standardisation of service descriptions.

P2P

Supports decentralised computation; high fault tolerance; highly scalable in resources and compute power.

Service quality cannot be guaranteed; security is difficult; performance depends on node count.

Event Bus

Easy to add new publishers, subscribers, and connectors; effective for highly distributed applications.

Scalability can be challenging because all messages pass through a single bus.

MVC

Multiple views can be built for the same model; views can be attached or detached at runtime.

Increases complexity; user actions may trigger unnecessary updates.

Blackboard

Easy to add new applications; flexible extension of data space structures.

Modifying the data space structure is hard because all applications are affected; may require synchronization and access control.

Interpreter

Supports highly dynamic behaviour; improves end‑user programmability; easy to replace the interpreter.

Interpretive languages are generally slower than compiled ones, so performance can be an issue.

For more detailed information, readers can follow the original source or join the architecture community groups mentioned at the end of the article.