Common Software Architectural Patterns and Their Comparison

Before starting software development, choosing a suitable architecture is crucial; this article briefly explains ten common architectural patterns, their usage, advantages, and disadvantages.

1. Layered Pattern

Also known as the multi‑layer architecture, it divides a system into layers where each layer provides services to the layer above it. The typical four‑layer structure includes Presentation (UI), Application (service), Business Logic (domain), and Data Access (persistence).

Use cases: general desktop applications, e‑commerce web applications.

2. Client‑Server Pattern

Consists of a server providing services to multiple clients. Clients request services; the server listens for requests and responds.

Use cases: email, file‑sharing, online banking.

3. Master‑Slave Pattern

Comprises a master component that distributes work to one or more slave components, which return results to the master.

Use cases: database replication (master DB as authoritative source), peripheral devices connected to a bus.

4. Pipe‑Filter Pattern

Used to build systems that generate and process data streams. Each processing step is encapsulated in a filter; data flows through a pipeline of filters.

Use cases: compilers (lexical analysis → parsing → semantic analysis → code generation), bioinformatics workflows.

5. Broker (Proxy) Pattern

Facilitates decoupled communication in distributed systems. A broker component mediates between clients and services, handling request routing.

Use cases: messaging middleware such as Apache ActiveMQ, Apache Kafka, RabbitMQ, JBoss Messaging.

6. Peer‑to‑Peer Pattern

Each component can act as both client and server, communicating directly with other peers.

Use cases: file‑sharing networks (Gnutella, G2), multimedia protocols (P2PTV, PDTP), proprietary apps like Spotify.

7. Event‑Bus Pattern

Handles events via four main components: event source, event listener, channel, and event bus. Sources publish events to channels; listeners subscribe to channels and receive notifications.

Use cases: Android development, notification services.

8. Model‑View‑Controller (MVC) Pattern

Divides an interactive application into Model (core data and logic), View (presentation), and Controller (input handling), promoting separation of concerns and code reuse.

Use cases: web applications built with frameworks such as Django, Ruby on Rails.

9. Blackboard Pattern Useful for problems without a deterministic solution strategy. Consists of a global blackboard (shared memory), knowledge sources (modules), and a control component that selects and executes modules. Use cases: speech recognition, vehicle tracking, protein structure identification, sonar signal interpretation. 10. Interpreter Pattern Defines a component that interprets sentences or expressions written in a specialized language, allowing easy evaluation of language constructs. Use cases: database query languages (SQL), protocol description languages. Comparison of Architectural Patterns Name Advantages Disadvantages Layered Pattern Lower layers can be reused by higher layers; standardization is easier; changes within a layer do not affect others. Not universally applicable; some layers may be skipped in certain scenarios. Client‑Server Pattern Provides a clear set of services that clients can request. Requests are often handled in separate server threads; inter‑process communication adds overhead. Master‑Slave Pattern Accuracy – execution delegated to different slaves with varied implementations. Slaves are isolated (no shared state); communication latency can be an issue; only suitable for decomposable problems. Pipe‑Filter Pattern Shows concurrent processing; easy to add or replace filters; reusable components; flexible pipeline composition. Overall efficiency limited by the slowest filter; data conversion overhead between filters. Broker (Proxy) Pattern Allows dynamic addition, removal, and relocation of objects, making deployment transparent. Requires standardized service descriptions. Peer‑to‑Peer Pattern Supports distributed computing; robust fault handling; high scalability in resources and compute power. No quality‑of‑service guarantees; security is hard to ensure; performance depends on node count. Event‑Bus Pattern Easy to add new publishers, subscribers, and connections; effective for highly distributed applications. Scalability may suffer because all messages travel through a single bus. MVC Pattern Allows multiple views of the same model, which can be attached/detached at runtime. Increases complexity; may cause unnecessary UI updates. Blackboard Pattern Easy to add new applications; extending the data space structure is straightforward. Changing the data‑space structure is difficult because all applications are affected; may require synchronization and access control. Interpreter Pattern Highly dynamic behavior; benefits end‑users by allowing custom scripting; flexibility because the interpreter can be swapped easily. Performance can be an issue since interpreted languages are generally slower than compiled ones.