Architecture Patterns

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.

Pattern :

• 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.

Pros :

• 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.

Cons :

• 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.

Example:

• General desktop applications.
• E-commerce web applications.

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.

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’.

Pros :

• 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.

Cons :

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

Example:

• Online applications such as email, document sharing, and banking.

Master-slave

“Master-slave architecture pattern” is useful when clients make multiple instances of the same request.

Pattern: 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.

Pros: 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.

Cons: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.

Example:

• In database replication, the master database is regarded as the authoritative source, and the slave databases are synchronized to it.
• Peripherals are connected to a bus in a computer system (master and slave drives).

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.

Pattern: 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’.

Pros: For compilers, 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.

Cons: This pattern is complex.

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

Example:

• Compilers. The consecutive filters perform lexical analysis, parsing, semantic analysis, and code generation.
• Workflows in bioinformatics.

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.

Pattern: 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.

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

Example:

• Message broker software such as Apache ActiveMQ, Apache Kafka, RabbitMQ, and JBoss Messaging.

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.

Pattern: 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.

Pros: 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.

Cons:

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

Example:

• File-sharing networks such as Gnutella and G2
• Multimedia protocols such as P2PTV and PDTP.
• Cryptocurrency-based products such as Bitcoin and Blockchain

Event-bus pattern

There are applications when components act only when there is data to be processed. At other times, these components are inactive.

Pattern: 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.

Pros: 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.

Cons: Testing of interdependent components is an elaborate process. If different components handle the same event requires complex treatment for 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.

Example:

• Android development
• Notification services

Model-View-Controller (MVC)

“Model-View-Controller (MVC) architecture pattern” involves separating an application’s data model, presentation layer, and control aspects.

Pattern:

• 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.

Pros: Using this model expedites the development.

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

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

Example:

Laravel, spring, rails

Blackboard

Emerging from the world of Artificial Intelligence (AI) development, the “Blackboard architecture pattern” is more of a stop-gap arrangement.

Pattern: 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 on 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’

Cons: 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 architectural 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.

Example:

• Image / Speech recognition
• Vehicle identification and tracking
• Protein structure identification
• Sonar signals interpretation.

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.

Pattern: 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.

Example:

• Database query languages such as SQL.
• Languages used to describe communication protocols.

Sources
https://nix-united.com/blog/10-common-software-architectural-patterns-part-1/
https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013