10 Most Common Software Architectural Patterns – NIX United - The first knowledge sharing application in Vietnam

Are you an entrepreneur planning to launch your IT application? Or, are you an enterprise IT manager in charge of building a new enterprise IT application? Before you start building your system, you need to decide the most appropriate software architecture. We explain the top 10 software architectural patterns here.

In this article, we will cover the most relevant questions regarding software architectural patterns:

Software Architecture Pattern: What is it?

Before delving into the common architectural patterns, let’s understand what software architecture is. Software architecture is a pictorial representation of the IT system that communicates the following:

The organization of the system;
Different components vis-à-vis their functions;
How the components interact with each other.

The schematic representation is an outcome of the design principles software architects use and the decisions they make. A typical software architecture requires decisions concerning security, performance, manageability, etc.

Why Should You Focus on Software Architecture?

The design principles, architectural decisions, and their outcome, i.e., software architecture together enable a software system to deliver its’ business, operational, and technical objectives. You need to get the software architecture right due to the following reasons:

A software development team makes the first set of decisions during the software architecture pattern selection. Only the business requirements are available before this stage. The first set of decisions are crucial in any project since sub-optimal decisions might result in budget and schedule overrun.
Your business stakeholders need to know about your progress. Software architecture acts as a visual communication tool, therefore they can understand the system you are building.
Software architecture models make it easy to reuse them in other projects since you now know the decisions you made and the various trade-offs.

How do You Know if Your Software Architecture is Good?

The following are indications that you have a good software architecture:

The software is easy to maintain;
Business stakeholders can understand it easily;
Good software architectures are usable over the long-term;
Such architecture patterns are flexible, adaptable, and extensible;
It should facilitate scalability;
The team can easily add features, moreover, the system performance doesn’t diminish due to this;
There is no repetition of the code;
The system can be refactored easily.

10 Common Software Architecture Patterns

It’s time to study the 10 most common patterns, so, here we go:

Pattern #1: Layered architecture

We often use ‘N-tier architecture’, or ‘Multi-tiered architecture’ to denote “layered architecture pattern”. It’s one of the most commonly used patterns where the code is arranged in layers. The key characteristics of this pattern are as follows:

The outermost layer is where the data enters the system. The data passes through the subsequent layers to reach the innermost layer, which is the database layer.
Simple implementations of this pattern have at least 3 layers, namely, a presentation layer, an application layer, and a data layer. Users access the presentation layer using a GUI, whereas the application layer runs the business logic. The data layer has a database for the storage and retrieval of data.

This pattern has the following advantages:

Maintaining the software is easy since the tiers are segregated.
Development teams find it easy to manage the software infrastructure, therefore, it’s easy to develop large-scale web and cloud-hosted apps.

Popular frameworks like Java EE use this pattern.

There are a few disadvantages too, as follows:

The code can become too large.
A considerable part of the code only passes data between layers instead of executing any business logic, which can adversely impact performance.

Pattern #2: Client-server

“Client-server software architecture pattern” is another commonly used one, where there are 2 entities. It has a set of clients and a server. The following are key characteristics of this pattern:

Client components send requests to the server, which processes them and responds back.
When a server accepts a request from a client, it opens a connection with the client over a specific protocol.
Servers can be stateful or stateless. A stateful server can receive multiple requests from clients. It maintains a record of requests from the client, and this record is called a ‘session’.

Email applications are good examples of this pattern. The pattern has several advantages, as follows:

Clients access data from a server using authorized access, which improves the sharing of data.
Accessing a service is via a ‘user interface’ (UI), therefore, there’s no need to run terminal sessions or command prompts.
Client-server applications can be built irrespective of the platform or technology stack.
This is a distributed model with specific responsibilities for each component, which makes maintenance easier.

Some disadvantages of the client-server architecture are as follows:

The server can be overloaded when there are too many requests.
A central server to support multiple clients represents a ‘single point of failure’.

Pattern #3: Master-slave

“Master-slave architecture pattern” is useful when clients make multiple instances of the same request. The requests need simultaneous handling. Following are its’ key characteristics:

The master launches slaves when it receives simultaneous requests.
The slaves work in parallel, and the operation is complete only when all slaves complete processing their respective requests.

Advantages of this pattern are the following:

Applications read from slaves without any impact on the master.
Taking a slave offline and the later synchronization with the master requires no downtime.

Any application involving multi-threading can make use of this pattern, e.g., monitoring applications used in electrical energy systems.

There are a few disadvantages to this pattern, e.g.:

This pattern doesn’t support automated fail-over systems since a slave needs to be manually promoted to a master if the original master fails.
Writing data is possible in the master only.
Failure of a master typically requires downtime and restart, moreover, data loss can happen in such cases.

Pattern #4: Pipe-filter

Suppose you have complex processing in hand. You will likely break it down into separate tasks and process them separately. This is where the “Pipe-filter” architecture pattern comes into use. The following characteristics distinguish it:

The code for each task is relatively small. You treat it as one independent ‘filter’.
You can deploy, maintain, scale, and reuse code in each filter.
The stream of data that each filter processes pass through ‘pipes’.

Compilers often use this pattern, due to the following advantages:

There are repetitive steps such as reading the source code, parsing, generating code, etc. These can be easily organized as separate filters.
Each filter can perform its’ processing in parallel if the data input is arranged as streams using pipes.
It’s a resilient model since the pipeline can reschedule the work and assign to another instance of that filter.

Watch out for a few disadvantages:

This pattern is complex.
Data loss between filters is possible in case of failures unless you use a reliable infrastructure.

Pattern #5: Broker

Consider distributed systems with components that provide different services independent of each other. Independent components could be heterogeneous systems on different servers, however, clients still need their requests serviced. “Broker architecture pattern” is a solution to this.

It has the following broad characteristics:

A broker component coordinates requests and responses between clients and servers.
The broker has the details of the servers and the individual services they provide.
The main components of the broker architectural pattern are clients, servers, and brokers. It also has bridges and proxies for clients and servers.
Clients send requests, and the broker finds the right server to route the request to.
It also sends the responses back to the clients.

Message broker software like IBM MQ uses this pattern. The pattern has a few distinct advantages, e.g.:

Developers face no constraints due to the distributed environment, they simply use a broker.
This pattern helps using object-oriented technology in a distributed environment.

Pattern #6: Peer-to-peer (P2P)

“Peer-to-peer (P2P) pattern” is markedly different from the client-server pattern since each computer on the network has the same authority. Key characteristics of the P2P pattern are as follows:

There isn’t one central server, with each node having equal capabilities.
Each computer can function as a client or a server.
When more computers join the network, the overall capacity of the network increases.

File-sharing networks are good examples of the P2P pattern. Bitcoin and other cryptocurrency networks are other examples. The advantages of a P2P network are as follows:

P2P networks are decentralized, therefore, they are more secure. You must have already heard a lot about the security of the Bitcoin network.
Hackers can’t destroy the network by compromising just one server.

Under heavy load, the P2P pattern has performance limitations, as the questions surrounding the Bitcoin transaction throughout show.

Pattern #7: Event-bus pattern

There are applications when components act only when there is data to be processed. At other times, these components are inactive. “Event-bus pattern” works well for these, and it has the following characteristics:

A central agent, which is an event-bus, accepts the input.
Different components handle different functions, therefore, the event-bus routes the data to the appropriate module.
Modules that don’t receive any data pertaining to their function will remain inactive.

Think of a website using JavaScript. Users’ mouse clicks and keystrokes are the data inputs. The event-bus will collate these inputs and it will send the data to appropriate modules. The advantages of this pattern are as follows:

This pattern helps developers handle complexity.
It’s a scalable architecture pattern.
This is an extensible architecture, new functionalities will only require a new type of events.

This software architecture pattern is also used in Android development.

Some disadvantages of this pattern are as follows:

Testing of interdependent components is an elaborate process.
If different components handle the same event require complex treatment to error-handling.
Some amount of messaging overhead is typical of this pattern.

The development team should make provision for sufficient fall-back options in the event the event-bus has a failure.

Pattern #8: Model-View-Controller (MVC)

“Model-View-Controller (MVC) architecture pattern” involves separating an applications’ data model, presentation layer, and control aspects. Following are its’ characteristics:

There are three building blocks here, namely, model, view, and controller.
The application data resides in the model.
Users see the application data through the view, however, the view can’t influence what the user will do with the data.
The controller is the building block between the model and the view. View triggers events, subsequently, the controller acts on it. The action is typically a method call to the model. The response is shown in the view.

This pattern is popular. Many web frameworks like Spring and Rails use it, therefore, many web applications utilize this pattern. Its’ advantages are as follows:

Using this model expedites the development.
Development teams can present multiple views to users.
Changes to the UI is common in web applications, however, the MVC pattern doesn’t need changes for it.
The model doesn’t format data before presenting to users, therefore, you can use this pattern with any interface.

There are also a few disadvantages, for e.g.:

With this pattern, the code has new layers, making it harder to navigate the code.
There is typically a learning curve for this pattern, and developers need to know multiple technologies.

Pattern #9: Blackboard

Emerging from the world of ‘Artificial Intelligence’ (AI) development, the “Blackboard architecture pattern” is more of a stop-gap arrangement. Its’ noticeable characteristics are as follows:

When you deal with an emerging domain like AI or ‘Machine Learning’ (ML), you don’t necessarily have a settled architecture pattern to use. You start with the blackboard pattern, subsequently, when the domain matures, you adopt a different architecture pattern.
There are three components, namely, the blackboard, a collection of knowledge resources, and a controller.
The application system stores the relevant information in the blackboard.
The knowledge resources could be algorithms in the AI or ML context that collect information and updates the blackboard.
The controller reads from the blackboard and updates the application ‘assets’, for e.g., robots.

Image recognition, speech recognition, etc. use this architecture pattern. It has a few advantages, as follows:

The pattern facilitates experiments.
You can reuse the knowledge resources like algorithms.

There are also limitations, for e.g.:

It’s an intermediate arrangement. Ultimately, you will need to arrive at a suitable architecture pattern, however, you don’t have certainty that you will find the right answer.
All communication within the system happens via the blackboard, therefore, the application can’t handle parallel processing.
Testing can be hard.

Pattern #10: Interpreter

A pattern specific to certain use cases, the “Interpreter pattern” deals with the grammar of programming languages. It offers an interpreter for the language. It works as follows:

You implement an interface that aids in interpreting given contexts in a programming language.
The pattern uses a hierarchy of expressions.
It also uses a tree structure, which contains the expressions.
A parser, external to the pattern, generates the tree structure for evaluating the expressions.

The use of this pattern is in creating “Classes” from symbols in programming languages. You create a grammar for the language, so that interpretation of sentences becomes possible. Network protocol languages and SQL uses this pattern.

Evaluating Software Architecture Patterns for Your Strategic Application?

Are you trying to find the best software architectural pattern for your key application? You need to make the right choice the first time, however, you need qualified software architects for that. It’s a hot skill. You might need a professional.