Architectural Patterns

Software architecture patterns focus on how applications can be organized at a higher level. They provide best practice solutions for some of the common problems such as ease of maintenance, deployability and scalability. Solutions written using common architectural patterns are easier to understand as they follow a widely recognized pattern.

In this article, let’s discuss some of the popular architectural patterns. It is worth noting that systems don’t strictly follow one of the patterns, often they follow a combination of architectural patterns based on application’s needs.

Monolithic Architecture

In a monolithic architecture, the entire application is a single executable unit often consisting of hundreds of thousands of lines of code. Well structured monoliths often follow a layered approach, namely database layer that interacts with the application’s database, business logic layer holding business logic of the application, and an interface or controller layer that is the main interface to application’s UI. Usually monolith applications start with a small set of functionality and often tend to grow over time as new features get added resulting in a single complex system that is harder to maintain.

Monoliths are

• Easier to get started with few resources

• Result in complex systems - often times it is hard for one person to understand the functionally of the entire system

• Usually entire application’s code base is part of one repository, this results in tight-coupled harder to maintain systems

It is often less expensive to replace monoliths with more modular systems than maintaining monoliths over time. Many large enterprise systems once started as monoliths have successfully replaced their solution to more modular subsystems.

N-tier Architecture

In N-tier architecture, applications are split into multiple tiers such as data tier, business logic tier and presentation tier. These tiers can be deployed in the same server or can be deployed individually. Often the application’s tiers are split based on technical boundaries. Data flows from one tier to the next without skipping a tier. Hence, some level of coordination is needed during deployment.

As the individual tiers can be independently scaled, N-tier architecture is an improvement over monolith architecture.

Service-oriented Architecture

Applications built with service-oriented architecture comprise of many loosely coupled services. Services are often broken by business functions. They have standard data contracts to communicate among services and use an enterprise service bus for inter-service communication.

Applications following service-oriented architecture are loosely coupled which is a great improvement over monolith and N-tier architectures. Since the coordination of data flow happens through the enterprise service bus, all services depend on the enterprise service bus. This could become source of the application’s unavailability when there are failures in the enterprise service bus.

Message-based Architecture

Messaging-based architectures in general are the ones that communicate with each other using shared messaging infrastructure. Messages are small pieces of self-contained information sent from one system to another often in a JSON format. There could be two types of messaging - queue based and publish / subscribe. Queue-based systems send information to one target audience. Publish / subscribe model broadcast information as topics and there could be multiple subscribers for a given topic.

Systems built using event-driven architecture are loosely coupled but often tend to be more complex as it is harder to fully get the big picture of various systems through which message (data) flows.

Microservices Architecture

In microservices architecture, a large system is made of small individual subsystems that work as peers to solve an application's problem. These individual services are self-contained and are backed by a small team that solely owns and manages the service. Microservices contain a few hundred lines of code resulting in easy to understand, test and deploy systems. Services could either communicate directly with each other or follow a message-based approach for inter-service communication.

Reactive Architecture

Microservices built using reactive systems tend to follow reactive architecture. Systems built as reactive architecture are more flexible, loosely-coupled and individually scalable.

Reactive Systems are

• responsive - they respond in a timely manner
• resilient - the system stays responsive in the face of failure
• elastic - work well in varying workloads
• message-driven - follow asynchronous messaging there by enabling non-blocking communication among services.

Serverless Architecture

A popular flavor of serverless architecture is a Function as a Service (FaaS) architecture. A function as a service architecture consists of multiple pieces of code called functions, which when invoked run a small container.

Advantages:

• Serverless architectures can easily scale when there is an increased demand
• As infrastructure of serverless applications is maintained by the cloud provider, there is no server maintenance overhead
• As there is no server provisioning overhead with this setup, it is very easy to experiment with new ideas

Disadvantages:

• As execution environment may get provisioned for every function invocation, functions deployed using serverless architecture cannot maintain state
• Cloud providers often have memory / execution duration limits for functions created in a serverless-way