ENABLING SOFTWARE PATTERNS

The architecture styles discussed above are complimented by software patterns which are used for fulfilling a technical goal of a solution, few of these patterns are also used widely in monolithic software products. They become useful when applied in the design to improve modularity, manageability, fail-safe, and redundancy.

Combined with the other architectures the architectural patterns can provide powerful hybrid architectures for solutions to best meet all requirements with minimum tradeoffs.

1. Microkernel pattern

Microkernel architecture is commonly used for developing on-premise applications. It involves a plugin-based software architecture which extends the functionality provided by the core software. This helps develop modular software features which can be loaded and executed on-demand or as per configuration stored in a plugin registry.

Microkernel can be combined with other architecture styles for modular sub-component architecture.

The interfaces between the core and plugins can be defined on any technology specific frameworks or at compile time using library integration through API calls or for remote deployment RPC, or ReST interfaces.

The basic topology of a Microkernel pattern comprises of following:

The characteristics of a microkernel pattern include:

Pros

Cost

Simplicity

Modularity

Extensibility

Cons

Limited scalability due to memory or database access constraint

Low elasticity

2. Pipeline pattern

Pipeline architecture is typically used to implement data pipelines for processing data in ETL or ELT pipeline through filters and tasks.

The pipeline architecture can be combined with any of the above architectures to ingest and process source of real-time or batch data.

A pipeline architecture is commonly used in hybrid IoT solutions. The applications can be implemented as any of the architectures mentioned in earlier sections. The data coming from IoT Edge is management through a data pipeline which can as well be used for performing batch analytics.
The basic topology of a Pipeline pattern comprises either of following:

The characteristics of a pipeline pattern include:

Pros

Scalability

Modularity

Cons

Cost

Elasticity

Fault tolerance

2. Circuit breaker pattern

In the implementation of SOA, services-based, or microservices architecture patterns there could be situations where services go down due to errors or are not able handle additional traffic. In these situations, the client would then need to keep waiting until time out. It is therefore prudent to implement a layer in between API layer and the services which can track the availability of the services and in case they are not reachable it can immediately send an appropriate error response, reducing the wait times and internal network traffic. This leads us to the Circuit Breaker (CB) pattern.

In operation, the CB can also suffice as an intermediary between an asynchronous request-response system. The main aspect of implementing a CB is to let know the client calling the API of any failures without long wait times.

The basic topology of a circuit breaker pattern comprises of following:

The sequence diagram describes the call sequence from a client to a service API and how a CB will aid to monitor health of backend services and give immediate responses in case of backend service failure.

The characteristics of a circuit breaker pattern include:

Pros

Fail safe systems

Abstraction from control / maintenance elements

Cons

Additional costs associated with deployment

Failure safety at risk if single CB for all API

3. Side car pattern and service mesh

Side car pattern is used to aggregate common control, proxy, and logging of microservices components together on a component named as a side car. Side car then communicates to a common service mesh fabric. The side car enables unified control and management architecture for microservices.

The side car pattern is useful for the implementation of service mesh in a microservices architecture deployment. Service mesh is an inter-connection of multiple side cars associated with each service. It is an out of band mechanism for service discovery, routing, proxy, and reliable service to service communications, unified API, and integrates unified components for observability and security.

The basic topology of a service mesh using side car pattern comprises of following:

The characteristics of a Sidecar pattern include:

Pros

Modularity

Resilient microservice architecture

Abstraction from control elements / non-function requirements

Improves maintainability by segregation of operational components into side car

Cons

Additional costs associated with deployment

High network traffic for frequent API calls

Additional resources, software, and tool to implement the service mesh control plane

3. Cache patterns

The cache systems with space-based, service-based, and microservices architectures work well to provide additional redundancy, and speed of execution.

Redis and memcached are popular for implementing in-memory caches. Redis, Apache Ignite, and Hazelcast are popular for distributed cache implementations.

Different methods of caching:

Distributed caches
Near-cache
Cache-aside
Read/write through caches and write behind cache

The basic topology of a cache pattern comprises either of following:

Pros

Speed

Redundancy of data

Fail safe systems

Cons

Eventually consistent

High network traffic for frequent synchronization

Not useful for static data