Software Architectural Patterns

Software architecture defines the blueprint or the structure in which Software components are organized in a software system. It also suggests the relationship between various software components and how they communicate with each other.

Software Architecture Patterns are general reusable software blueprints that could be used for specific software engineering problems, given specific context. There are various types of Software Architectural Patterns. In this document, we will cover a few which are used most frequently with their advantages and disadvantages.

Architectural Patterns

Monolith

A monolith architecture is the traditional blueprint of software in which all the components are coupled within one component itself, generally within the same code base e.g. an e-commerce Java web application, contained within a WAR file deployed on a web container, containing everything from UI to Backend APIs for all use cases e.g. Inventory management, user profile management, order management, etc., including database interactions. Monolith architecture can prove to be a useful software architecture for software systems very early in their life cycle, as it minimizes overload by reducing the time required in code management, deployment, etc.

Advantages

1. Easy deployments: Since the whole functionality is built within one monolith, leads to easy deployments.
2. Easy testing: Since there is only one service, there are fewer cases to cover and thus the time required for testing is relatively less.
3. Faster execution: Since there is only one monolith that performs all the functions, thus eliminating the need for services to talk, the time required to perform the action is relatively less.
4. Debuggability: Improved debuggability as all the code base is in the same component itself.

Disadvantages

1. Reliability: An error in one component can bring down the whole service.
   
2. Scalability: Since it's a monolith, we can't scale individual components based on the actual traffic pattern of each component.
3. Technological stack: Individual components can't adapt their technological stack based on their requirements. The whole service needs to be on the same stack.
4. Deployments: Since it's a monolith, any change in any component requires redeployment of the whole service.

Microservices

Microservices architecture is the blueprint in which a software system has independent, loosely coupled services. These services could have their own interfaces, databases, and infrastructures. These could be updated, tested, and deployed independently. Every service in this architecture pattern can scale up or down based on its own needs. It could appear that Microservices architecture makes the service organization more complex by bringing in more movable components, however, its not the case. Microservices architecture makes the complexity of a system more manageable by breaking down components into smaller, manageable components, which can function independently while not impacting other components, by adhering to a defined contract.

Advantages

1. Reliability: An error in one component will not bring down the whole software system.
2. Scalability: Individual components can scale better based on their requirements
3. Technological stack: Every component can have a technological stack based on what works best for it e.g. a User profile system could use NoSQL as a datastore rather than mandatorily using an SQL datastore because the software was using it.
4. Faster iterative development: Since the software system is broken down into more manageable components, it leads to better parallelization of work and thus faster and independent deployments and feature releases.

Disadvantages

1. Increased infrastructure and maintenance cost: Every microservice would need its own infrastructure and maintenance e.g. testing, upgrades, operational burden, etc., thus increasing the costs.
2. Increase in latency: Microservices architecture consists of multiple software systems, that interact with each other, thus adding latency because of the communication overhead required.
3. Debuggability: Debugging could be a challenge with Microservices architecture as the logs or traces are spread across services and cannot be in the same format, thus requiring more time when needed.

Layered (N-Tier Architecture Pattern)

This architecture pattern organizes software components into horizontal layers, with each layer playing a specific role in the software system e.g. an e-commerce software system containing four layers in its software stack — database, persistence, business, and presentation. Each layer consists of software components that perform related functionality e.g. persistence layer will work as the Software ingress and outgress for actions requiring interaction with the database.

Advantages

1. Ease of development: Relatively simple to make changes and develop new features as it's easy to understand layers and it also aligns well with organizational structures (organizations having different teams/layers for different skilled employees).
2. Debuggability: Debugging is easy as every layer has a clean boundary and has clear interfaces and expectations.

Disadvantages

1. Performance: This architecture choice might not be a good choice for high-performance systems as performance takes a hit when a request has to go through multiple layers of systems rather than serving it through just one system.
2. Scalability: A layer could contain multiple components performing similar actions, but not necessarily at the same scale e.g. a User profile updation might not have the same RequestsPerSecond (RPS) requirements as it is for creating or updating orders. This means a layer is tending to be a tightly coupled monolith and thus difficult to scale based on individual components requirements. This can be mitigated by breaking a layer into multiple independent components, but that adds up infrastructure costs and other scaling concerns.

Event-Driven Architecture Pattern

This architecture pattern details systems reacting to an outside event. Software systems in this architecture pattern interact with each other by exchanging events. A system could "announce" to the world when a particular business action is performed e.g. an order is placed. The software systems interested in this event, would listen to this announcement and "react" to it by performing certain actions e.g. shipping the item to the customer when the order is placed. The software system announcing the event is called Publisher and the software systems listening to the events are called consumers.

Advantages

1. Eventual Data Consistency across multiple systems
2. Atomicity and simpler transactions within each software system

Disadvantages

1. Complex transaction management across systems as multiple services need to perform the transactions within each scope
2. Relatively higher latency in performing the action across systems

Master-Slave Architecture Pattern

This architecture pattern is most suited for software systems requiring performing similar actions repeatedly but on different inputs and in parallel e.g. a Software system requiring querying the order details of customers at a large RPS in parallel.

In this architecture pattern, there is a master component and multiple slave components. The master component assigns the work action to the slave components and slave components perform the work and return the response to the master component. The master component could then either calculate the final response based on responses from the slave or return the response based on any slave's response.

Advantages

1. Parallelization: Actions can be performed in parallel thus increasing the performance of the system.
2. Scalability: Improved scalability of the systems as new slave nodes can join whenever required and better scale out the load.

Disadvantages

1. Complexity in dealing with master component's failover: Additional mechanisms need to be put in place to handle the failover of the master node.
2. Complexity in dealing with Partial updates: All slave nodes might not complete the actions at the same time. Some could even fail as well, which requires additional complexity in the master node to handle.

Client-Server Architecture

The client-server architecture pattern comprises two components. Client, who is the requester, requesting an action; and server, who performs the action. In this architectural pattern, generally, the client and server interact over a network. A simple example of this is the World Wide Web.

Advantages

1. Simplicity: Each component has a clean responsibility. The client requests an action, Server performs the action.
2. Performance: A Server can perform actions requested by multiple clients, thus leading to optimization of performance over the software systems.

Disadvantages

1. Single point of failure: If the server fails, none of the requests could be processed. This could be mitigated however by building additional guard rails to prevent the server from failing.
2. Higher Cost: Servers are relatively expensive to maintain.

Model View Controller (MVC) Architecture

An MVC architecture defines software components to be classified as Model, View, and Controller.

The model defines the core application data of the Service. It contains the structure of the data, not how the data is used in the Business actions. It also doesn't define how the data is presented to the users of the software systems.

The view defines how the core application data is presented to the users and how the user could interact with it. View doesn't know how the data is manipulated within the Software System.

The controller handles the input from the users and manipulates the data defined in the model based on the input from the customers. It does this by operating on the data elements defined in the Model.

These components interact with each other using mechanisms like notifications e.g. an external notification from the user (showing account details of a customer) would be handled by the controller to update the view (account details of the selected customer).

Advantages

1. Simplicity: Each component has a clean responsibility and thus is easy to develop.
2. Ease of collaboration: A change in UI doesn't impact changes in the backend (and vice-versa) till the interface is maintained, thus leading to improved collaboration in development.

Disadvantages

1. Interfaces of the components need to be strict to maintain the quality of the pattern and its advantages.
2. Increased complexity in code to maintain the three components cleanly over time.