How To Choose the Right Software Architecture Pattern

We’ve written before about software architecture on this blog, explaining how important it is to structuring complex IT systems. So we know that without robust software architecture, you’ll likely end up with a big ball of mud. And we know that software architecture patterns are common blueprints for designing and organizing software systems. But which of these architecture patterns should you use for your application?

As with most things in software development, there is no one-size-fits-all best solution when it comes to making this decision. It may be tempting to jump on the latest hot trend, but success lies in finding the architecture pattern that is most suited to your organization’s unique requirements, resources and capabilities. Here we’re going to run the main benefits and problems with five of the most common software architecture patterns - as identified by experienced software architect Mark Richards - to help you make the right decision on which you should use.

Pros and Cons of 5 Common Architecture Patterns

These are five well-established patterns, which means they are structures that are known to work. They have already been designed, deployed and tested in the real world, and are currently widely used in different contexts.

Layered (N-Tier) Architecture Pattern

This is the most common of the established software architecture patterns and organizes system components into horizontal layers. A typical structure includes three/four standard layers: presentation, business, persistence (this may be integrated into the business layer in smaller systems), and database. The presentation layer is outward-facing and the entry point for user data, which then passes through the other layers down to the innermost database layer.

Crucially, each layer has a specific responsibility and provides a call or service to the next layer - requests must pass through each layer before moving on to the next. This is a key concept of this pattern, providing structure by isolating the layers so that they operate independently of each other. This makes it possible to modify the components in one layer without affecting the operations of all the others.

Pros: It is relatively easy to understand and quick to develop, with closed layers offering a high level of control to aid testing and maintenance.

Cons: It lends itself to monolithic applications (limited flexibility), and even small modifications can require complete redeployment of the app. It can also be inefficient if data requests are running through multiple layers that are really performing any function.

Event-Driven Architecture Pattern

In this pattern, software components are decoupled and set up to asynchronously identify, process, and respond to ‘events’, such as a mouse click or keystroke. The pattern consists of two topologies – mediator and broker.

The mediator topology uses a central unit as a ‘mediator’, receiving information from event producers and assigning it to the relevant event processors. This is needed when multiple steps of an event need to be coordinated.

With the broker topology, events flow along a ‘chain’, with each processor performing one function and passing it on down the line until all steps are completed. The event-driven pattern is commonly used in e-commerce applications: by placing an order, a customer initiates an event that triggers a response from the different event processor modules (e.g. confirm order, calculate VAT, notify the client).

Pros: The pattern is very agile and scalable due to its decoupled, single-purpose event processor components.

Cons: It can be complex to develop and tricky to test due to its asynchronous nature.

Microkernel Architecture Pattern

This system is made up of a core unit (the ‘microkernel’), which is the entry point for data, and a number of independent plug-in components with specific functions. The microkernel deals with the basic routine functions and data flow to make the system operational; the plug-in components have specialized, stand-alone responsibilities. Importantly, the core unit and its functions are not affected by - or concerned with - the implementation of these plug-in features.

This pattern is commonly used for software products like operating systems that provide basic functionality out of the box but can then be easily adapted and customized. It can even be embedded within another architecture pattern if it is better-suited to deal with just one area of an application.

Pros: It is highly flexible, with the ability to easily integrate new plug-in modules to add more business capabilities or adapt to changing system requirements.

Cons: It is not typically suitable for larger and more complex applications (though as stated it can be embedded within other patterns). The core microkernel unit can be difficult to modify once it is operational and has a number of plug-in components already dependent on it.

Microservices Architecture Pattern

This is a very popular pattern today, with Netflix one of the earliest and most high-profile adopters (it is now estimated to be used by around three-quarters of businesses). The core concept is to replace traditional monolithic applications with a system of multiple, decoupled components (‘microservices’) that are deployed separately but work with each other.

This pattern allows large, complex applications to be broken down into smaller and more management building blocks that communicate with each other through simple Application Programming Interfaces (APIs). Each component is self-contained, meaning that developers can work on one microservice without disrupting the broader functionality of the whole application.

Pros: It is highly versatile and scalable, while the separation of components helps reduce the risk of a small error bringing down an entire application. Testing is also easier on the segregated and self-contained service components.

Cons: It is challenging to set up and may be overly complex for small applications. Defining the degree of granularity for each service component can be problematic, while the pattern’s distributed nature increases the number of points that could be vulnerable to a security breach.

Space-Based (Cloud) Architecture Pattern

This pattern provides a solution to bottlenecks and congestion when there is a high volume of requests. It does this primarily by removing the central database, which is vulnerable to failure on sudden spikes in user load, and splitting processing and storage across multiple servers. There are two main components: a processing unit that contains application components and a virtualized-middleware component that deals with data synchronization and communications. It is particularly useful in applications when usage is volatile and there may be sudden peaks in volume.

Pros: Removing the central database allows for near limitless scalability and helps prevent crashes on usage spikes.

Cons: It is complex to develop and testing the main function of this pattern (coping with higher user loads) is difficult.

--

There are other software architecture patterns available, but these are usually a good starting point for when you’re beginning on a new app. Remember, a software architecture pattern is not the same as a design pattern. Both do offer reusable solutions to common problems, and there are some similarities that can lead to confusion over which is which. The fundamental difference is that architecture patterns are relevant to high-level design choices while design patterns tackle lower-level problems within the global structure. If we were talking about a house, architecture patterns would be the blueprints for how the building will be constructed while design patterns provide core solutions for how the interior is designed and furnished.

If you want to stay up to date with all the new content we publish on our blog, share your email and hit the subscribe button.

Also, feel free to browse through the other sections of the blog where you can find many other amazing articles on: Programming, IT, Outsourcing, and even Management.