According to Wikipedia,

“An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context. Architectural patterns are similar to software design patterns but have a broader scope.”

Let’s look at a few common architectural patterns,

Monolithic Architecture

In monolithic architecture, the entire program is one large executable unit. Sometimes specified with hundreds of thousands of lines of source code. A well-structured monolith can give you needed efficiency at the cost of very slow and painful deployment.

But there is a drawback with a monolith, which is that everybody’s afraid to touch it, even a small change can cause problems in unexpected places. Work that should take a few hours can take weeks.

Microkernel (plugin) Architecture

The main idea behind the Microkernel (plugin) architecture is to put the essential capabilities of your system into a single stand-alone executable. for example, In an operating system, the kernel handles virtual memory and the file system. Other capabilities are implemented as stand-alone execution units that effectively plug into the kernel to do their work.

Microkernel architectures are a step up from monoliths in several ways. The main one is that the plugins are largely independent of one another. Typically, the plugins don’t know how other plugins work or if the other plugins even exist for that matter.

The plugins are also relatively small and easy to write, debug, and maintain, so you don’t have the problems associated with not being able to find things, or of the system being so complex that you can’t possibly understand it. On the downside, the kernel itself, or more correctly the APIs to the kernel, are very delicate. If you need to make a necessary change to those APIs, all of the plugins might need to be rewritten to use the new APIs.

Message-based Architectures

This architecture takes the notion of a microkernel a step further by formalizing the communication paths between elements and isolating them even further.

In message-based architecture, A common message bus controlled the flow of communication. Each application was fitted with a so-called adapter that talked to the message bus on one side and talked to the application on the other.

In another model of message-based architecture which is called pub/sub model,

Publishers publish messages associated with a specific topic. Subscribers can subscribe to a topic and receive messages from any publisher on that topic.

Message-based architectures allow the components of the system to be isolated in extreme ways. Each component is effectively a small, standalone program that can be maintained independently of other programs. That decoupling makes your system vastly more maintainable than a monolith, and it solves the dependency problems of a microkernel system.

On the downside, messaging systems quickly become highly complex, and managing that complexity is difficult.

Microservices and Miniservices

In a microservice architecture, the larger system is made up of a cloud of very small independent services that cooperate as peers to get the larger work done.

In the earlier chapter that discussed defense storming, you’d implement the agents or entities that emerged from that exercise as individual microservices. Those services can be spread across a network, even across the whole internet, and redundancy is built-in. Many instances of the same service, for example, could run in parallel. Put those things together and you get a very resilient system that can easily handle whatever stress you throw at it. Microservices are not just tiny monoliths. They have to be designed in a way that supports distributed deployment and complex real-time interactions.

microservices should be

• be independently deployable

• translates into a few hundred lines of source code

• written in a way that hides all the implementation details

• designed to work in an unreliable network environment

• highly observable, They log everything they do. You can monitor how well they’re running in real-time. So if services fail, you know why they failed.

  
  

When you implement microservices the main problems usually have to do with how the services communicate with each other. People take two main approaches.

The first is to make each service a small HTTP-based web service that you talk to using a REST-like protocol. The main downside of a post-based API is that it’s inherently synchronous, rather heavyweight, and has several error modes that are difficult to solve.

The second approach is messaging instead of HTTP.

There are many advantages to microservices, particularly in an agile environment where you constantly need to make small changes to a handful of services and deploy them very quickly.

The main downside of microservices is they come with a lot of both design and runtime complexity. Getting multi-step operations to work reliably across a network is just plain hard work. Microservices also come with a speed hit. Networks are just slow when compared to other alternatives.

Reactive and Choreographed Systems

In a Reactive and choreographed system, the system is issuing events instead of making requests. It broadcasts the event to the world, and any downstream services that are interested in that fact can do whatever they need to do in order to handle the event.

Reactive and choreographed system is faster than microservice architecture. All of the downstream processing is easily done in parallel, so the worst-case latency is typically the processing time of the slowest downstream process.

I hope this article helped you to learn about a few architectural patterns and their benefits and drawbacks., If you want to learn more you can follow the work of Grady Booch, Mark Richards, Simon Brown, and Neal Ford.

Do comment and share and let me know if you like it, your small effort encourages me to write more.

Also Published here