10 Common Software Architectural Patterns: Part 1

Logo NIX

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 with building your system, you need to decide the most appropriate software architecture. We explain the top 10 software architecture patterns here.

Software architecture pattern: what is it?

Before delving into the common architecture 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?

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. 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 the database for 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 patter.

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, for e.g., monitoring applications used in electrical energy systems.

There are a few disadvantages to this pattern, for 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 in use. 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 filter 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 architecture pattern are clients, servers, and brokers. It also has bridges and proxies for client and server.
  • 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, for 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.

Follow our updates to find the second part of the text, where we explain other five common software architecture patterns.