Which Architecture Patterns Should You Be Using?

When bespoke software and Applied A.I. solutions for clients across multiple sectors and geographies, a dynamic range of effective architecture patterns is essential. Whether it’s developing a new web app to enhance the user experience or using A.I. to predict consumer purchase probability, every project brings unique challenges, goals and technical requirements. That’s why we work hard on continuously refining which architecture patterns to keep in our arsenal.  

Over the years, we’ve deployed new patterns, dropped old ones, and tried different combinations based on the latest theory from the field, the technology that’s available and the evolving needs of our customers. We thought we’d share the current architecture patterns found in our tech stack. Hopefully, this will give you an idea of the capabilities and benefits of each, and help you decide which ones might be best for you.

Service-Oriented Architecture (SOA)

Service-oriented Architecture (SOA) is an approach where an application uses services available within the network, using a communication call over the internet. The most obvious benefit to this is that you can combine a large number of facilities in one streamlined and cohesive system. With Microservices (see below) as one of our core architecture patterns, SOAs are becoming less and less relevant in our projects, since they use a common data store. Another drawback is that SOAs use an Enterprise Service Bus (ESB), which acts as a single point of failure for the entire system. The service decoupling found in a Microservices approach is much more reliable and better meets the needs of our projects, which is why we’re leaving SOAs behind.

Microservices

Microservices form a core part of our technical processes and are a popular pattern choice for engineers looking to move away from monolithic architectures. Often using the principles of SOAs, Microservices break apart these systems to form collections of “loosely coupled” services – each responsible for an individual feature. The best part about this is the ability to develop, deploy and maintain each individual service on a different platform, using different programming languages, tools, and even storage systems if required. This makes projects with Microservices architecture extremely flexible, resilient and scalable, while also reducing time to market and speeding up the CI/CD pipeline. 

Event-Driven Architectures (EDA)

Fitting within a Microservices approach, Event-Driven Architectures (EDAs) focus on the generation and handling of event notifications (modifications in application state). One of the most significant benefits of this is the flexibility it provides, as the continuous monitoring of incoming events allows the system to make decisions in real-time. It’s a much more adaptive approach compared to a more traditional request-driven model and meets the needs of today’s businesses, who are competing in an on-demand economy. Since EDAs make such good use of real-time information (which is more abundant than ever before), they’ve become a go-to pattern for a large number of our projects.

Event Sourcing

An approach within EDAs, Event Sourcing has become a core architecture pattern in the development of our bespoke software. Unlike a more traditional way of storing a single application state, Event Sourcing instead captures a series of state changes. This can be extremely insightful as it not only shows what a current application state is, but also reveals how that state was reached by reconstructing it using past events. It also means you can determine an application state at any previous point in time, rather than being limited to the current state. This comes in handy for many of our projects, especially where clients need to gain better insights from the data captured by their applications. 

Command Query Responsibility Segregation (CQRS)

Since using Event Sourcing for so many projects, we’ve found Command Query Responsibility Segregation (CQRS) to be a really complementary approach. Simply put – and as the name suggests – CQRS separates data stores for writing (command) and reading (query), allowing you to focus on each element independently. This makes the software much more scalable. A major consideration when implementing CQRS is how to make the projection between the two data stores share application states. The best way to do this is to use event-driven projections in a persistent event store, which – since we are using Event Sourcing – we already have. This makes CQRS a perfect match for Event Sourcing architectures. Of course, there are instances when CQRS shouldn’t be used, which we have detailed in our recent blog post.  

Choosing Your Own Architecture Patterns

Do some research online and you’ll soon find that the use of most architecture patterns are supported and contested in the software engineering community.  You’ll find arguments for and against most approaches, so how do you decide which ones to use? The truth is, all patterns have their benefits and limitations, and some work better when used alongside others. The key is to consider your choices in a wider business context. Think about which ones would suit the skills and expertise of your people, meet the needs of your clients and integrate neatly into your other business practices (think operational processes, the size of your teams, the sectors you serve etc.).

To stay up to date with the latest news, product updates and some of the cool projects we’ve been working on, sign up for the Intelygenz newsletter.